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
a. Media types to describe representations
b. Uniform interface to allow visible interactions, so that clients
and intermediary infrastructure can follow the interpret all
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
"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
"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
"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
"4. Not being tied to HTTP, the model is open to peer to peer Data
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.
Note that history solutions that rely on changing the URI with those
fragment identifiers and require the app to "re"create the previous
view are confusing to the end user. As I discussed in  below, the
correct behavior is to let the browser present "its" view of the
previous page without the app reconstituting it programmatically.
You are right about HTML5.
> Is Gmail or Facebook, which uses history, confusing for its users?
I don't know what happens behind the scenes, but the key point I am
making is that, when a user clicks on the back button, what the user
expects is the browser's view of the previous page. Some of the apps I
have seen try to recreate the view based on the state as known to the
app. In some cases, these two views could be different, and that is
what can confuse users. The difference may be subtle in some cases,
but not always. Apps should not have to recreate views when the user
is navigating browser history.
No apologies needed, but not sure why you had to "cringe". This
discussion is about some fundamental concepts and not word games.
Don't mean to pick on your remarks, but it is good to get the concepts