Very interesting discussion indeed. I've been experimenting with
building visual REST applications – I used <a
href="http://www.frevvo.com";>frevvo</a> and
<a href="http://www.restlet.org";>Restlet</a> (I work for frevvo). I've
posted a couple of blog articles about my experiences and I'm definitely
interested in knowing how other people are building visual web
applications with REST. You can find much more including diagrams,
examples and source code at:
<a href="http://www.frevvo.com/blog/?p=26";>Visual REST apps: Part 1</a>
<a href="http://www.frevvo.com/blog/?p=32";>Visual REST apps: Part 2</a>
I tend to think in terms of View Resource (forms) that compose Entity
Resources (documents). The View Resource can update existing entities,
create new ones, store locally or update remotely – all in a uniform
RESTful manner. IMO, it's a very powerful and flexible way to interact
with the web and create REST applications that handle complex visual
elements without compromising REST principles.
I'd be very interested in your thoughts.
Thx,
-Ashish
Matthieu Hug wrote:
Vincent <vincent.lari <at> yahoo.ca> writes:
Hi Matthieu,
Hello Vincent
You'll find comments within the text below. Best regards,
Basically I've a rich client application (Flex) accessing
Ah, but it's quite a different story, as the final (visual) representation is
assembled on the client, not on the server.
Absolutly.
I considered each resource as
being kind of a "virtual web page", with one URI and one (or several if
required) "layouts" (representations). The application accesses the required
resources, and assembles them for display.
So if one page displays A and B, and another page displays A, B, and C,
A knows it has two layouts (a/B and A/B/C). If you later add D to the page,
you'll add a third layout for A. Is that correct?
"layout" is really misleading, sorry about that: it was meant to relate to
restlet's representation (the way the resource is viewed by the client), not to
the display within the client. All resources are represented as atom feeds: so
the representation (which I wrongly called "layout") in restlet sense is this
atom feed; then the client displays it as it wishes. So A does not know (and
shouldn't IMHO) it can be dispayed with B or with B/C. If D is added later, and
it is independent from A and it is only a client issue.
An important point is that each resource includes links to all other
resources it is logically linked to: the client has absolutly NO
knowledge of the links between resources, it virtually navigates between
them as needed. If A is linked to A and B, when the client accesses A it
receives its representation, including a link to B and a link to C;
Let say these resources are independent one of another (For instance if
A is a weather report, B a news feed, and C your profile). Who is responsible
for linking them together? Does A know it's linked to B and C, or are these
associations established at a higher level?
If resources are independent there're not linked together. The link must be
meaningful in a business sense. There could definitly be a higher level resource
that associates independent resources. For instance, let's say that your example
relates to a personal mashup, something like google personal page or netvibes.
Then you could consider that C contains links to B and A (the user chose B and A
among a series of mashups, and its part of his profile), but A and B are not
linked together (another user could use A without B). In that case C would stand
for the higher level resource.
A's representation contains a link to B and C, which means the client has
to GET and C, and pass their representation to the template in order to
generate the page. So, do B and C's representations contain links to A?
The client indeed navigates through the resources and the links provided in
their representation exactly like a human would navigate through web pages: it
has no other knowledge than the links provided by resources (no resource can be
accessed if it is not linked by a previously loaded resource).
Then it is not mandatory to have symmetric links. Resources are really
analoguous to web pages: many pages have links to Amazon, but Amazon does not
have symmetric links to all of them. However until now symmetric links proved
to be useful to navigate between resources of the application.
-vincent.
