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.
> 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.
I am definitely a proponent of moving UI logic to the client (one of the main points of SOFEA), but I certainly agree with your points, I think it is critical that we build on HTTP, not against it. It is certainly my ambition that we can leverage the RESTful architecture that HTTP provides, thanks for your comments.
> 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.
This isn't true, "single page" apps have long-supported navigation and book-markability using hash/URL fragments, and HTML5 is providing further standardization of the hash/JS interaction (partly due to some bugs in IE's handling of hash changes and the difficulty in track them from JS side of the user agent). There is nothing anti-RESTful about "single page" apps, it just makes the JavaScript part of the user agent in HTTP interaction (and hence it is so important that the JavaScript actually understands and leverages HTTP properly, as I think you are advocating). Thanks, Kris
>> 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.
> This isn't true, "single page" apps have long-supported navigation and > book-markability using hash/URL fragments, and HTML5 is providing > further standardization of the hash/JS interaction (partly due to some > bugs in IE's handling of hash changes and the difficulty in track them > from JS side of the user agent). There is nothing anti-RESTful about > "single page" apps, it just makes the JavaScript part of the user > agent > in HTTP interaction (and hence it is so important that the JavaScript > actually understands and leverages HTTP properly, as I think you are > advocating).
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 [1] below, the correct behavior is to let the browser present "its" view of the previous page without the app reconstituting it programmatically.
An important question before I get to my main point ...
Is this forum for both TSA and SOFEA? Is the main goal promoting and
discussing Thin Server Architectures? Is SOFEA an offshoot?
In my opinion, I think we are burning rubber with SOFEA (generating a
lot of smoke without going anywhere). If the core message of this
group is TSA, SOFEA's constraints are distractions to that core
message. SOFEA gives too much fodder for the elite programmers to
tear apart.
As a related aside ...
I cringe when I hear statements like:
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.
My sincere apology to Subbu for picking on this statement. I feel
like the group gets too caught up in semantics and word games. No one
cares. We sound like a bunch of Grad students.
These ideas are going to be a success not based on formal
descriptions, but by clearly communicating the advantages of TSA. I
know about 4 different companies that are just trying this 'java'
thing after programming for AS/400 for the last 10 years.
At the end of the day, 90% of developers don't really care if they are
following the standards of the web or following what was originally
intended. They care about doing whatever makes their clients happy
the easiest. When they think of that, they should think of TSA.
In my opinion, TSA is easier to build more engaging applications.
That is all that matters.
On Oct 28, 12:52 pm, Subbu Allamaraju <su...@subbu.org> wrote:
> 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.
> >> 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.
> > This isn't true, "single page" apps have long-supported navigation and
> > book-markability using hash/URL fragments, and HTML5 is providing
> > further standardization of the hash/JS interaction (partly due to some
> > bugs in IE's handling of hash changes and the difficulty in track them
> > from JS side of the user agent). There is nothing anti-RESTful about
> > "single page" apps, it just makes the JavaScript part of the user
> > agent
> > in HTTP interaction (and hence it is so important that the JavaScript
> > actually understands and leverages HTTP properly, as I think you are
> > advocating).
> 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 [1] below, the
> correct behavior is to let the browser present "its" view of the
> previous page without the app reconstituting it programmatically.
> 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.
I agree that at the end of the day what matters is whether we have stumbled upon methods of developing web applications that really does make development and maintenance cost less or if we're just kidding ourselves.
Much of my own argumentation and research (if one can call it that) have been in justifying the general ideas without being too specific about the implementation. OK, I _have_ been specific about what I prefer, but also that it is just my cup of tea (JSON, love and let live :).
The SOFEA specification as it stands is very much geared towards large, multifaceted intranets, where SOA is the common factor binding systems together. Even if Ganesh and his team may have some detail wrong, or have been misinterpreted, this does not take away the central message of it.
I am not a scholar myself, and like Justin I'm a very pramgatic person, but that also mean that I'm blind on those eyes (Not really a Swedish saying, but nevermind). Perhaps the discussion over the detailed implementation can and will be important to future technologies, or perhaps even the current ones.
And I still feel that there is so much common ground between TSA and SOFEa that I don't feel any immediate need for this to turn into a splintering of any sort. TSA is very coffee-discussion simple and open - OSFEA is very specific and detailed for a specific (and very common) enviroment. No problem there.
Also, I get the feeling that Subbu agrees on the general ideas of TSA and SOFEA at heart and only have issues with certail details of SOFEA. Isn't that so?
Cheers, PS
On Tue, Oct 28, 2008 at 7:42 PM, Justin Meyer <JustinBMe...@gmail.com>wrote:
> Is Gmail or Facebook, which uses history, confusing for its users?
> On Oct 28, 1:37 pm, Subbu Allamaraju <su...@subbu.org> wrote: > > >> 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.
> > > This isn't true, "single page" apps have long-supported navigation and > > > book-markability using hash/URL fragments, and HTML5 is providing > > > further standardization of the hash/JS interaction (partly due to some > > > bugs in IE's handling of hash changes and the difficulty in track them > > > from JS side of the user agent). There is nothing anti-RESTful about > > > "single page" apps, it just makes the JavaScript part of the user > > > agent > > > in HTTP interaction (and hence it is so important that the JavaScript > > > actually understands and leverages HTTP properly, as I think you are > > > advocating).
> > 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 [1] below, the > > correct behavior is to let the browser present "its" view of the > > previous page without the app reconstituting it programmatically.
Subbu, thank you very much for pointing me to this group!
I'm developing my first TSA web app, so I'm here to learn and to share
my experience.
Btw, I'm using smartclient LGPL for the UI (6.5.1 but waiting for the
7.0 release...)
Claudio
On 28 Ott, 18:52, Subbu Allamaraju <su...@subbu.org> wrote:
> 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.
> Subbu, thank you very much for pointing me to this group!
> I'm developing my first TSA web app, so I'm here to learn and to share > my experience. > Btw, I'm using smartclient LGPL for the UI (6.5.1 but waiting for the > 7.0 release...)
> Claudio
> On 28 Ott, 18:52, Subbu Allamaraju <su...@subbu.org> wrote: > > 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.
> 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.
> My sincere apology to Subbu for picking on this statement. I feel > like the group gets too caught up in semantics and word games. No one > cares. We sound like a bunch of Grad students.
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 right.
On 29 Ott, 12:47, "Peter Svensson" <psvens...@gmail.com> wrote:
> I haven't used Smartclient, but I saw it demoed at AjaxWorld recently. How
> do you find it in terms of usability, features, ease of development, et.c.?
I must confess that I rejected to use jquery because their UI lacks
features that I absolutely need (i.e. grids), and also rejected ExtJs
due to the licensing policy...
Beware: I don't want to start a smartclient vs extjs flame!
but I think that in terms of usability extjs is better than
smartclient. Maybe also a bit more responsive. I'm waiting for the 7.0
release because there will be new skins, and I hope in a positive
impact on usability. Forgive me if I'm plain wrong :-)
Features: very rich! I'm very impressed, I still haven't discovered
all features...their demos page can take a while to load (better to
disable firebug) but I think it's impressive.
I like the databinding and the validation. In my project I will load
dinamically the description of forms, layout and validation, in json
format...and I'm planning to interpret the validation rules written in
json format to do the server-side validation, also (I think their
commercial server side components do this).
ease of development: maybe a bit hard to start, but the docs are good
to me, and the developer console is great.
The commercial version has also a "visual builder":
http://www.smartclient.com/releases/vb_video.htm
Yes I saw their demos on AjaxWorld recently. I myself use mostly Dojo. I think that the central theme for most of the toolkits used in building TSA / SOFEA applications is that they have an official data model which cleanly separates the widgets that consume or use data from the service or place that provides it. Dojo has this, and so has JavaScriptMVC and ExtJS. And of course Smartclient. I don't think that jQuery have any common standard around data management, but I'm not really the one to ask.
I did get a comment today on my blog, where Andrej Koelewin said that he had made almsot the same kind of presentation that I had at my Google tech talk, but using jQuery instead :)
Which proves that it works anyway. But concerning that, one of the things I like to see coming out of the OpenAjax alliances work is an open standard data API between various layers in a client-side app, so that we can reuse each others components and data sources.
Cheers, PS
On Thu, Oct 30, 2008 at 11:34 PM, claudiobosticco <
> On 29 Ott, 12:47, "Peter Svensson" <psvens...@gmail.com> wrote: > > I haven't used Smartclient, but I saw it demoed at AjaxWorld recently. > How > > do you find it in terms of usability, features, ease of development, > et.c.?
> I must confess that I rejected to use jquery because their UI lacks > features that I absolutely need (i.e. grids), and also rejected ExtJs > due to the licensing policy... > Beware: I don't want to start a smartclient vs extjs flame! > but I think that in terms of usability extjs is better than > smartclient. Maybe also a bit more responsive. I'm waiting for the 7.0 > release because there will be new skins, and I hope in a positive > impact on usability. Forgive me if I'm plain wrong :-) > Features: very rich! I'm very impressed, I still haven't discovered > all features...their demos page can take a while to load (better to > disable firebug) but I think it's impressive. > I like the databinding and the validation. In my project I will load > dinamically the description of forms, layout and validation, in json > format...and I'm planning to interpret the validation rules written in > json format to do the server-side validation, also (I think their > commercial server side components do this). > ease of development: maybe a bit hard to start, but the docs are good > to me, and the developer console is great. > The commercial version has also a "visual builder": > http://www.smartclient.com/releases/vb_video.htm
On 30 Ott, 23:53, "Peter Svensson" <psvens...@gmail.com> wrote:
> Dojo has this, and so has JavaScriptMVC and ExtJS. And of course
> Smartclient. I don't think that jQuery have any common standard around data
> management, but I'm not really the one to ask.
I recall I read a post on their dev group where they said they were
developing it.
> I did get a comment today on my blog, where Andrej Koelewin said that he had
> made almsot the same kind of presentation that I had at my Google tech talk,
> but using jQuery instead :)
good, I'll take a look at it together with yours :-)
> Which proves that it works anyway. But concerning that, one of the things I
> like to see coming out of the OpenAjax alliances work is an open standard
> data API between various layers in a client-side app, so that we can reuse
> each others components and data sources.
On 30 Ott, 23:53, "Peter Svensson" <psvens...@gmail.com> wrote:
> Yes I saw their demos on AjaxWorld recently. I myself use mostly Dojo. I
> think that the central theme for most of the toolkits used in building TSA /
> SOFEA applications is that they have an official data model which cleanly
> separates the widgets that consume or use data from the service or place
> that provides it.
another framework which I think has got this feature is Qooxdoo, also
used by the RAP Eclipse project.
|
