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
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
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