At a session on "RESTful Web Apps - Facts vs Fiction" [1] at the
Colorado Software Summit, I briefly discussed about SOFEA
misinterpreting the web architecture, in particular, the uniform
interface and hypermedia as representing application state and not
just data. Some one in the audience pointed me to this group, and so I
am posting my comments here.
The text in quotes below is from the SOFEA paper.
"Thus, the REST approach accomplishes loose coupling between systems
using the standard vocabulary of the web – HTTP verbs and URL nouns, a
“contract” that hides actual implementations behind a common façade –
the REST Service Interface. "
It is more than that. Loose-coupling in REST can be achieved via the
following:
a. Media types to describe representations
b. Uniform interface to allow visible interactions, so that clients
and intermediary infrastructure can follow the interpret all
interactions
c. Link relations to describe URIs [2,3]
d. Hypermedia as the engine of the application state, viz.,
representations contain not only data, but also contain the state of
the application in the form of contextual links.
Secondly, please don't coin terms like "REST Service Interface". REST
is not an interface. The interface that exists in REST or HTTP is a
"uniform interface", viz., a generic interface with a fixed set of
operations.
"Whenever we use a client device to run an application (and this
client device could be a workstation or any of the newer handheld
devices we all own and love), three separate and distinct processes
take place, whether we realise it or not:
1. Application Download (AD)
2. Presentation Flow (PF)
3. Data Interchange (DI)"
IMO, this kind of separation works only for "single page"
applications, where you download the entire app (HTML + JS + others)
when a user hits a URI, and subsequently, all interactions happen over
XHR. By focusing on just such applications, the app will not be able
to support browser navigation and book-markability, which by the way,
are not broken unless an app breaks them by poor implementation choices.
Secondly, although you mention the download server being different
from the "business logic" server, due to same origin policy, from the
clients point of view, these are the same. Hence, the suggested SOFEA
architecture has a much narrower scope and relevance on the web.
"This lack of respect for data as data is a fundamental characteristic
of HTML over HTTP. It has been with us since the inception of the web,
but no one seems to mind. "
No one seems to mind because it works. More importantly, this process
is not lossy. If you consider the architecture of the WWW, you will
find that how data is transmitted between clients and servers is
dictated by media types. A media type such as "application/x-www-form-
urlencoded" or "application/xhtml+xml" specify information is encoded.
Just because a media type prescribes stuffing parameters into a single
string (such as "p1=v1&p2=v2") does not mean that it is mistreating
the data. A different media type, such as "application/vnd.myorg.person
+xml" may specify a different encoding of information, say, as an XML
document with an underlying XSD or RNG schema. Concluding that the
current web is not respecting data is gross misinterpretation of the
web architecture. Instead of looking for schemas, look for media type
specifications.
"It is not possible to trigger a Presentation Flow in a web
application without initiating a Data Interchange operation (e.g., a
GET or a POST). More vexingly, every Data Interchange operation willy
nilly results in a Presentation Flow. It's a classic case of tight
coupling between two orthogonal concerns. ... In hindsight, it might
have been better if they had been completely broken, because then
this aspect of the thin client architecture would have been fixed."
IMHO, this argument is a stretch. HTML was designed for navigation,
and navigation involves sending a representation (of a given media
type) or following a URI and then fetching a new representation. This
is what makes a generic client such as a browser work.
"Although ingenious, the POST Redirect GET pattern is mere band aid
over the fractured web architecture. "
Where did the authors get this idea from? IMHO, this paper is
misinterpreting the difference between non-idempotent operations and
idempotent operations.
"Use XML to define data structures, data types and data constraints
for the application end to end. "
I think this approach is ignoring media types and links, and is in
stead focusing on passing data around. The key downside of this
approach is that the code downloaded will be strongly coupled to the
so-called "business logic" server as the code needs to understands how
to construct URIs and guess what URI accepts/returns what kind of
representations.
"4. Not being tied to HTTP, the model is open to peer to peer Data
Interchange."
IMHO, this is a mistake. SOAP/WS made the same mistake of treating
HTTP as a transport protocol. Please don't repeat it. By ignoring
HTTP, you are also ignoring the uniform interface and all the
semantics that go with it such as caching, optimistic concurrency,
idempotency and safety. Consequently, apps built using SOFEA will not
be able to scale and perform the way users expect the web to work.
Apps will also be forced to invent proprietary mechanisms to account
for concurrency. This is a slippery slope.
To summarize, by relying on XHR and such technologies, there are more
opportunities to take advantage of the RESTfulness of the web
architecture. This paper makes some honest attempts for Ajaxy single-
page applications, but claiming that the current web is broken is a
gross misinterpretation. By relying on HTTP's uniform interface, and
by using media types and links, it is possible to build richer and
RESTful applications that take advantage of the web architecture and
not fight against it.
Sincerely,
Subbu
http://www.subbu.org
[1] http://www.subbu.org/blog/2008/10/slides-from-the-colorado-software-s...
[2] http://www.subbu.org/blog/2008/09/on-linking-part-1
[3] http://www.subbu.org/blog/2008/09/on-linking-part-2
|
