My tech talk at Google
Peter Svensson
http://unclescript.blogspot.com/2008/10/tech-talk-on-thin-server-architecture.html
Cheers,
PS
Justin Meyer
arguments for TSA. Added a quick link to our blog: http://javascriptmvc.com/blog/.
I'm going to use about 60% of your talk.
>
> Cheers,
> PS
Peter Svensson
Kris Zyp
towards more of a REST focus as an aim of this group. It is certainly an
uphill battle to attempt to evangelize a new acronym (SOFEA or TSA),
when in fact REST (if it is understood properly, IMO) actually embodies
the same concepts that you are pursuing. I think I mentioned this
before, but section 5.1.2 [1] actually states: By separating the user
interface concerns from the data storage concerns, we improve the
portability of the user interface across multiple platforms and improve
scalability by simplifying the server components. This sounds very close
to the goals of SOFEA. While many people seem to think REST simply means
using GET requests with a certain style of URLs, the REST architecture
as a described by Fielding is actually principals to apply to facilitate
minimizing the processing requirements of the server (TSA) and enabling
clients (SOFEA):
Statelessness - Application state remains on the client (hypertext
as engine of application state), servers can remain stateless, reducing
their complexity
Uniform Interface - Data is discovered and interacting with through
a uniform standard interface, allowing the data to drive applications.
This further reduces server complexity because custom interfaces and
APIs do not need to be designed, generic infrastructure and interface
can be utilized.
Code-On-Demand - REST is designed for code to be delivered to the
client to enrich the user experience
Of course REST is based on extensive academic and empirical research,
there is a solid foundation there. By preaching REST (rather than
something new), you can leverage the existing popularity and buzz around
REST, while focusing on some of the lesser understood concepts (seems
very few people actually understand REST) that are synonymous with
service oriented front end architecture with thin servers. Anyway, just
a suggestion, an idea to consider, obviously that is where my focus is...
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Kris
Peter Svensson
PS
Craig McClanahan
> Hi Kris,
> I think that this is a good move in general, but I don't think that REST
> covers everything. I'm not trying to be a wet blanket here :) but we are
> trying to define more than just data interaction. For example, a lot of
> things get very weird if you try to map then onto REST operations, like a
> login. Also, getting the schema out of a RESTive table is also something I
> would recommend using RPC for, since it's meta-data, which kind of muddles
> the domains if you use the same table to manage that, as well.
> So to define separation of concerns in terms of protocol (instead of client
> or server-perspective) we need at least RPC also. But then it doesn't get
> as clear-cut (or maybe it does, and it's just me).
> But I think that REST is definitely in there in the core.
> Cheers,
> PS
While it's clear that SOFEA intends to encompass more than data
transfer, and I like the way you have been thinking there, I would
echo Kris's recommendation in slightly stronger terms: if you claim
that REST is not *sufficient* for the data transport layer, the
RESTafarian community that does exist will reject *all* your ideas.
All they need point at is "we need at least RPC also" to do that. And
that would be too bad.
Examples of RESTafarian responses you are going to get:
* Why do you need login at all? (Of course, this will quickly
morph into a stateless versus stateful interaction discussion,
so the real question is "are you claiming you need stateful
interactions with the server? if so, why?"
* Why would retrieving mundane things like a database schema
be better suited to RPC than REST? To me, that's pretty much
a perfect use case for a REST approach, because the metadata
is just a resource that can be queried (in whole or in part).
I'd hate to see all your other good ideas about TSA get ignored on this basis.
Craig McClanahan
Peter Svensson
Kris Zyp
proclaiming "you should follow this architecture that I thought of or
named, etc", it might be easier to say "there is significant benefits in
following these principles of the REST architecture which Roy Fielding
described and are the proven, tested foundations of web and it's
scalability". You can disseminate the ideas of TSA/SOFEA as principles
of REST rather than new concepts, and I think you can do so without even
taking sides how strictly one needs to follow REST or whether or not one
needs to avoid any REST constraint violations (certainly many people
claim to use REST, and perhaps even benefit from REST architecture, but
still have REST violations (like authenticated sessions)). Many people
understand that REST is a powerful architectural pattern to follow, but
are unclear on what is involved. Discussing the benefits of the REST's
statelessness, uniform interface, and code-on-demand principles as
arguments for TSA may be easier for people to accept and you don't even
need to get into the other principles or try to convince people of the
entirety of REST for such benefits to be realized. I didn't really
intend to argue whether or not REST can and should be used to solve all
problems, just that it is highly regarded architecture (and rightly so)
and thus preaching principles with REST as the reference source is more
likely to be well-received (and rightly so).
Kris
Craig McClanahan
> Hi Craig,
> Thanks for your good riposte :)
> Actually, I'm not absolutely certain that REST cannot be the be-all, end-all
> of data communication betweena client and a server, I'll just see if I can
> come up with something that is not sensitive.
> Let's say that you need to access a resource on the server that is
> calculated on the fly, like the result of a grid calculation, or the current
> GPS position of a car. Of course, these things could also be mapped onto a
> REST object property that is read.
It sure can. Only your server knows for sure what's static and what's
dynamic :-).
> As for metadata, I've always felt that it is unclear where metadata for a
> REST 'table' should be accessed. Under /table/schema, under /schemas/table
> or something else? Since this (IMO) feels undefined, I would fel more
> comfortable moving it out of the domain entirely. OTOH, if people can just
> agree on a standard for this, it owud make things easier.
Well, there are a lot of hierarchical relationships in our data models
one could reason about. Examples:
* Customers -> Orders -> Line Items
* Databases -> Tables -> Columns
So it seems like the same decomposition principles (and URI
determinations) could be done in both domains. Just one possible
approach:
* Get a customer: GET /customers/{accountId}
* Get a database description: GET /databases/{databaseName}
* Get orders for a customer: GET /customers/{accountId}/orders
* Get tables metadata for a database: GET /databases/{databaseName}/tables
and so on. There's lots of ways to skin this cat, but hierarchical
data models map pretty naturally to hierarchical URIs. (It gets fun
when you have many-to-many relationships, though :-).
In the scenario above, you'd probably support create (POST), update
(PUT), and delete (DELETE) interactions to the customers, orders, and
line numbers data models, but probably only support GET on the
database metadata. That's perfectly fine.
All of that being said, a word of caution is in order. Pretty URIs
are *not* a primary goal of REST -- that's really for human
consumption. The key principle in REST that lots of people miss is
that your data representations (the XML or JSON or whatever you send
back and forth) should include hyperlinks for all the related data you
might want. The general way I would state this principle: a client
application should *not* need to understand how the server's URIs are
composed -- it should be able to contact a canonical "service
discovery" URI and be able to follow links from there." This is a
little overly ambitious when applied universally, but it's a good
measuring stick for your data model design.
Just as one example, let's say you have a "get customers" call that
includes filtering and pagination options (for this, I like "count"
and "offset"). It's real typical for a front end UI to want to
present results in a paginated way, so lets make that easy:
GET /customers?offset=30&count=10
Now, lets include some useful links in the response (I'm using XML by
habit ... same principle applies with JSON):
<customers>
<link rel="previous"
href="http://server.example.com/customers?offset=20&count=10"/>
<link rel="next"
href="http://server.example.com/customers?offset=40&count=10"/>
<customer>...</customer>
<customer>...</customer>
...
</customers>
Now, when the UI wants to respond to a "Previous Page" or "Next Page"
button click, it doesn't have to "know" how to manually compose the
correct URI ... it just uses the right href from a <link>.
> Does anyone know there's some kind of prejudicing discussion about this, so
> as not to reinvent the wheel? I'm fine in general with using REST only for
> everything, but I have a nagging feeling that it doesn't suffice. I'm
> happily proven, or implied, wrong, however.
I get a lot of my RESTful inspiration from seeing how the Atom
Syndication Format[1] and Atom Publishing Protocol[2] were put
together. While the initial problem domain for Atom was blogs and
posts, the principles can be applied to *any* problem domain, by using
custom content data elements, or a custom namespace, in addition to
the standard elements. In addition, using the standard CRUD
interaction patterns from AtomPub makes your application both easy
understand, and easy to develop. It is instructive to see lots of
publicly available APIs (consider GData) that are taking this path.
In the big picture, figuring out the right URI structures, and
including the right hyperlinks, are "medium sized" steps along the
path to REST. In my experience, REST newcomers tend to have more
problems with the stateless constraint than anything else :-). But
that also turns out to be where some of the biggest benefits
(particularly in scalability) can come from.
> Cheers,
> PS
Craig
[1] http://tools.ietf.org/html/rfc4287
[2] http://tools.ietf.org/html/rfc5023
Peter Svensson
PS
Peter Svensson
PS
Craig McClanahan
> Craig, thanks for the very good discussion on urls, et.c. I guess I can
> manage to use REST principles for everything, in principle.
> In practice, though, I think I'll use rpc for some stuff anyway, but I do
> agree that it seems that REST would suffice.
You can certainly do that if you choose ... but you'll be back to
skipping the opportunity for RESTafarians to support SOFEA. At best
they'll ignore it. At worst, they'll bash it ... *especially* if you
were to claim to be RESTful but still have non-RESTful
characteristics. You're expected to "walk the walk, not just talk the
talk" if you say you're RESTful :-).
> I also agree to the hyperlinkedness of resources, and to abstract the same
> away from the users of the data. Dojo has stores that can manage references
> in items, both internal, external and circular. A component reading the
> data, only ask to get the value of property x, and the rest is managed.
> I also thought the same when reading the GData spec; It felt like nothing
> much more was needed, especially the 'checking out' of resources for
> editing, et.c. Really neat.
If you run into something where you're puzzled about how to implement
it RESTfully, feel free to send it to this list -- I'll hang around.
But I've got to admit (although I suspect this is no surprise) ...
I've become a RESTafarian myself (hopefully considered a nice one :-),
so my personal interest in SOFEA will remain "oh, cool ideas, too bad
it's useless to me" if its not really RESTful.
BTW, my "day job" at Sun is building the server side of some
"interesting" web services that will become public later, and
designing the RESTful APIs for them. Our team doing the UI work is in
fact using these RESTful interfaces already, achieving the kind of
separation goals you talk about even though the UI implementation
technology still has server side elements to it. But we're going to
get the same sorts of benefits from this separation.
> Cheers,
> PS
Craig
Justin Meyer
Correct me if I am wrong, but by 'in practice', I think Peter means in
his actual use, not necessarily how he describes it when presenting
it.
Personally, I think TSA is easy to understand at its core -> client =
UI, server = data.
I have a much harder time describing how to implement it.
On Nov 25, 9:36 pm, "Craig McClanahan" <craig...@gmail.com> wrote:
Peter Svensson
REST might be the only thing needed for C/S communication, but the problem I'm trying to solve is how to describe to people that the most efficient architecture to use when building web apps is one where you separate concerns between client and server, so that the server does not have any client state (and most probably, no state at all).
What Kris say is that by adopting REST as a description of what we're doing (which might be or might become true) we can hitch a ride on an existing movement without paving the road brick by brick all the way.
This is all well and good, but I feel that by reducing the discussion to focus on the protocol, instead of the architectural issues, what might happen is that people think that we're just speaking about REST and don't have time for the small print.
I'm trying to talk about a better way of planting forests, not whether the Birch is the greatest tree. Focus on Birches (great trees!) might lead to great forests, as this is implied in how the Birch works as a tree, but it is still one step removed from the central discussion.
Cheers,
PS
Ganesh and Sashi Prasad
I've been following this discussion with interest.
One way to approach this would be to first ask the question, "How can
a *rich* client interact with server-side resources?"
We risk muddying the waters if we straightaway begin to talk about
clients built using web technology, because that's the space in which
REST also plays. The line between our view of REST (as a provider of
business logic services to the UI) and the REST folks' view of REST
(as a capable driver of the UI itself) becomes confusing.
So first consider (say) a Win32 VB app built on Windows and managing
all UI components. All data resides on a server-side database. We
would like to interface between this VB client and the server-side
data using a higher-level protocol than ODBC.
If REST is proposed as that protocol, then we in turn position the
SOFEA Data Interchange mechanism as the way the client talks REST.
Application Download and Presentation Flow have already been factored
out of the equation because the application is manually installed on
the client (through MSI) and VB components handle all Presentation
aspects in their native way.
Once we establish this interaction model (and we can show a parallel
model to interface the Win32 app with SOAP services), we can extend
this to an application that is installed onto a virtual platform like
a Java Virtual Machine, i.e., a Java application. Application Download
could be in real-time through Java WebStart. Presentation Flow is
managed natively in Java Swing, analogous to the Win32 case. The
interface with REST and SOAP then remains similar to the Win32 case.
Finally, extend the model to one built using AJAX/Web technology.
First consider a Single Page Application (SPA) that gets downloaded in
real-time (like a Java WebStart app) to a virtual machine (the browser
platform rather than a JVM). Presentation Flow is still managed
internally using JavaScript rather than Java. The interaction model
with REST and SOAP then remains the same as in the previous two cases.
The non-SPA case where plain templates are served up from a Download
Server is a mere extension of this last model.
I think that step-by-step development of the SOFEA model covering
three different technologies is the best way to avoid confusion with
REST's own UI management model.
I don't see the two as contradictory. I just don't see the REST UI
model as being exclusionary to other UI approaches. We need to point
that out by starting with a case where REST clearly doesn't apply
(e.g., a Win32 client app).
Regards,
Ganesh