On May 10, 2007, at 11:25 AM, Ittay Dror wrote:
> i'm having a hard time understanding your explanation. can you
> please post two examples, one "RPC plus streaming", the other true
> REST?
RPC is remote procedure call. One of the things that typical RPC
mechanisms lack is the ability to describe responses (or even
parameters) as a stream of data as opposed to a small data type.
HTTP has no problem doing that even when it is used in an RPC way.
So, people who advocate "resource-oriented" as an end in itself,
as if the only thing you need to build a network-based application
is a URI template and resource definition language, are just fooling
themselves into thinking what they are doing is REST. Resources
are just one part of the style. Resources are necessary for REST,
but resources must be allowed to evolve independently from the
clients and the only way that can happen is when the clients are
expecting to be instructed by the next representation received.
Otherwise, the client is making assumptions about the server's
implementation --- assumptions that will break eventually --- and
becomes much more complex and brittle than the type of network-based
application that REST is intended to encourage.
That is why hypermedia as the engine of application state is
an essential constraint of REST, and why RESTful application
frameworks cannot ignore the need for meaningful media types,
whether it be in the form of microformats or specialized XML
data types.
i'm having a hard time understanding your explanation. can you please post two examples, one "RPC plus streaming", the other true REST? i assume you're not ...
... RPC is remote procedure call. One of the things that typical RPC mechanisms lack is the ability to describe responses (or even parameters) as a stream of...
So if I understand correctly: take the case of the shopping cart. REST-like implementation will return a representation of the shopping cart as a list of...
... Based on the requirements above, I'd probably look at a shopping cart profile of the Atom format (application/atom+xml) and protocol (add/edit/delete...
... That's not a problem specific to the REST style, or even computing. What it does it put that problem in an appropriate place. "What about meaning ?" is the...
... So, since the XML result returned by the Atom Publishing Protocol does not include hyperlinks with each entry for deleting that entry, or updating it, or...
... APP defines <link rel="edit" href="..."/> in atom:entry elements for deleting/updating entries. The service document defines <collection href="..."/> for...
... Wow, I did not know that about the APP! I must admit I've never given it a close reading. Now that I know about them, I do believe they satisfy the HEAS...
... Well, for Atom the constraint is that the collection URL itself is the one that you use to POST to. So I _think_ that this is already available, but it's...
... And such a separation is right there in the thesis paper, in section 6.2.3, paragraph 2: "In order to author an existing resource, the author must first...
I have argued that APP is "less-weblike" than HTML applications because you don't send documents in response to the instructions in a form. You build the...
... Yes. This is obviously different from the situation on the web, where you build an application/x-www-form-urlencoded string according to a recipe you read...
... Well, the body of an url-encoded form data request entity, that you send to one service URL, can vary over time, so it's easy to evolve it. Also, the...
... a) atom:content can carry content of any MIME type. b) Entries can have any number of atom:link and atom:category elements with varying @rel or @scheme...
... The prinicple difference is that for url encoded form data, the server described to you the information it needs to perform an action. In the app case, or...
... You mean like how you can read the recipe for interacting with a form in I don't know, is it 3, specs? ... The form tells you no such thing. What you are...
... Unsure if you mean there are 3 specs that define from fields semantics? Or just 3 specs touching on HTML forms? ... Running out of gas here, Bill... got a...
Roy T. Fielding wrote: "So, people who advocate "resource-oriented" as an end in itself, as if the only thing you need to build a network-based application is...
... I was asked to review an early draft, but I don't know how far that was (or is) from their current draft. I really don't have the time. Sam's a smart guy...
... [. . .] ... This is where I get a little confused. I assume that the client still needs to understand each of the possible states so that it knows what to...
... Each state is described by the current set of representations. A client's understanding will depend on its understanding of the media types. ... The client...
... So where (today) I might validate some input, and dependent on n state variables.... present A or B or C, now I simply generate links (for a human...
Wow. This thread, along with Tim Ewald's recent blog post on REST and state machines has really clarified REST for me. At least I think it has... Let me try to...
... And you can explain it like this: Have URI, will follow. K. -- Blacknight Internet Solutions Ltd. <http://blacknight.ie/> Unit 12A Barrowside Business...
... That is a little too trivial. Maybe like this: Have representation with URIs, will follow. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>...
... I sure would be curious to know! :) ... Can you share your the slides after your talk? ... It's as an effective visual mnemonic to tie everything together....
... I'll take a stab: A slide on State. As Tim Ewald put it in his recent personal revelation concerning REST: "The essence of REST is to make the states of...
... I've found it's a valuable means to explain REST to people with an RPC/Web services background: in a WS-* scenario, you have a fixed number of "endpoint"...
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email
