I finally get REST. Wow.

Yeah, I'm alive. And I remember the password to my blog. I've been away for a bit, working on something very cool involving the TV. If all goes well, you'll hear about it in a big way. Anyway, I'm still having a ball out here in reality. Building something real has a way of focusing your decisions about technology. My app is a distributed system, some of which runs in a cable plant head-end or telco office (whatever's on the other end of the wire in your living room), and some of which runs elsewhere. We also connect to some things on the Web. These connections have to be extremely flexible and the bar to adoption has to be low. The thing I finally realized (some of you will say “Duh!”) is that Web services are not a good way to do this.

It's depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again. I know SOAP is really an XML messaging protocol, you can do oneway async stuff, etc, etc, but let's face it. The tools make the technology and the tools (and the examples and the advice you get) point at RPC. And we know what the problems with RPC are. If you want to build something that is genuinely loosely-coupled, RPC is a pretty hard path to take.

That realization would have gotten me down if not for the fact that something else jazzed me up an hour or so later. I was in the process of considering the alternatives when I finally understood REST. And wow, it was eye-opening. REST is often positioned as CRUD operations against entities identified by URIs. Then it is dismissed as to simplistic to be useful. You can't build with just CRUD, the reasoning goes, just think about why we write sprocs. I've been down that path any number of times and always ended up in the same place. But I had it all wrong.

I skimmed Fielding's thesis a while back, but it wasn't until I read Sam Ruby's recent posts that it really sank in. Here's what I came to understand. Every communication protocol has a state machine. For some protocols they are very simple, for others they are more complex. When you implement a protocol via RPC, you build methods that modify the state of the communication. That state is maintained as a black box at the endpoint. Because the protocol state is hidden, it is easy to get things wrong. For instance, you might call Process before calling Init. People have been looking for ways to avoid these problems by annotating interface type information for a long time, but I'm not aware of any mainstream solutions. The fact that the state of the protocol is encapsulated behind method invocations that modify that state in non-obvious ways also makes versioning interesting.

The essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you're moving to, making that your new state. A state's representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app's protocol can't work that way too. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)

The “state machine as node graph traversed via URI” view of the world has really interesting implications for being able to suspend and resume a protocol. Because links to other states are embedded in a state's representation there are interesting ways to solve dynamic load-balancing, data-directed-routing, versioning and other problems using normal Web infrastructure. And because it's HTTP based, you get all the features that protocol supplies, including streaming and support for non-XML MIME types (a huge concern when you're doing TV stuff). The one thing that's really missing here is a simple framework for implementing a URI graph on top of an HTTP handler (similar to what Marc's been working on for Java). I'm building my own now.

The thing I love about this model is that, as Sam says, it is of the Web, not over the Web. That doesn't mean I'll use it for everything. I use TDS to get to SQL Server. I use WCF for RPC-style communication between distributed components within major systems. I'll use this model when I cross major system boundaries, especially when I don't own both sides. I'll let you know how it turns out.

Comments

# re: I finally get REST. Wow.
Chris Ortman
Posted @ 4/26/2007 5:40 PM
Great post. I've been toiling back and forth all week trying to choose between REST / Soap. I currently use soap, but the only reason for that is that's what makes ASMX happy, and I constantly get that queezy feeling because that framework either limits me or makes me get into all kinds of hairy details just to send someone some xml. You mentioned you're working on something like a URI graph on top of HTTP handler. I've done a little bit of experimenting with fitting this behaviour into MonoRail (http://www.castleproject.org/monorail/index.html) I just haven't had balls to try this approach full on due to lack of time but so far my results have been pleasing.
The 2 things I think it really offers at the moment are a convenient way to render XML using view engines and a solid architecture for pulling the data off the wire and putting it into my object model (I am not a big fan of xml serializer).
# re: I finally get REST. Wow.
dave howard
Posted @ 4/26/2007 6:22 PM
sam ruby's link should be intertwingly.net instead of intertwingly.com
# re: I finally get REST. Wow.
Tim
Posted @ 4/26/2007 6:40 PM
Doh! Fixed the link to Sam, thanks Dave!
# re: I finally get REST. Wow.
Dennis
Posted @ 4/26/2007 6:51 PM
Woah....that is beautiful. You just changed the way I think about the entire Web.

I've been building webservices in .Net ever since .Net came out, never really paid much attention to REST.

Time to start googling.
# re: I finally get REST. Wow.
Dennis
Posted @ 4/26/2007 7:03 PM
So, I've got Fielding's thesis, before I get started on all that I have one newbie question...how does that state transfer physically work? Ie., what is the REST equivalent of hyperlinks in HTML?
# re: I finally get REST. Wow.
Brian Maso
Posted @ 4/26/2007 8:40 PM
I've been working on a SOAP-based protocol, PSP (www.powersportsstandardprotocol.com) for about half a year. This is a standard based on OAGiS. To sove the state problem, PSP uses a 2-part request, where the first part is a "Verb" and the second part is a "Noun". The noun, identified by a unique UUID, is a unit of knowledge owned by one side of the conversation (the "supplier"). PSP defines standardized verbs for requesting information or performing state transitions on nouns.

Examples of noun type include things like a "purchase order", a "warrantee claim" etc. For each noun type, the spec defines a state model. Using a noun.verb request, the client (a.k.a. "dealer" in PSP speak) makes requests of state changes in the original noun. There are also some simple query verbs a dealer uses to gather information about a noun.

So there's some definite similarities with what Tim is describing about REST I think: the idea of requests being commands to a finite state machine engine to move an addressable entity between states, or to gather information about current states.

The lack of a standard for endpoint descriptions in REST is a bit problematic for B2B applications. But the brain-dead use of WSDL/Schema as an RPC endpoint description makes SOAP a very annoying B2B electronic interlingua also. Use of SOAP almost always with HTTP(S) is brain-dead as well.
# re: I finally get REST. Wow.
Brian Maso
Posted @ 4/26/2007 8:45 PM
Oops, got the URL wrong: www.powersportsstandardprotocol.org
# re: I finally get REST. Wow.
Mark Baker
Posted @ 4/26/2007 9:31 PM
Dennis - state transfer refers to the exchange of data between agents, where the data represents the state of a resource at some point in time. Regarding links, links in HTML are RESTful; for other data formats, they'd also have to use links.
# re: I finally get REST. Wow.
Mark Baker
Posted @ 4/26/2007 9:32 PM
Brian - the lack of "standard endpoint descriptions" in RESTful systems is a feature, not a bug. All resources expose the same interface, therefore there's no value in describing the differences because there aren't any!
# re: I finally get REST. Wow.
Harold
Posted @ 4/26/2007 10:56 PM
Good stuff by Joe Gregorio here: http://bitworking.org/news/How_to_create_a_REST_Protocol.
# Tim Ewald Gets REST
Stefan Tilkov's Random Stuff
Posted @ 4/27/2007 12:32 AM
Tim Ewald: I was in the process of considering the alternatives when I finally understood REST. And wow, it was eye-opening. REST is often positioned as CRUD operations against entities identified by URIs. Then it is dismissed as to simplistic to be useful. You can’t build with just CRUD, the reasoning goes, just think about why we write sprocs. I’ve...
# re: I finally get REST. Wow.
Danny
Posted @ 4/27/2007 4:21 AM
Tim, nicely put. This might amuse you : http://dannyayers.com/engine-of-state/on
# Care to elaborate for a given example?
Ittay
Posted @ 4/27/2007 7:13 AM
Say I want to model a chess opponent in REST. Now, in RPC, one major procedure would have been makeNextMove, which would have returning the move.

How do you do that in rest by modeling states? The obvious response is creating some URI like http://example.com/next_move that accepts GET. But isn't this just RPC?
# re: I finally get REST. Wow.
Bill de hOra
Posted @ 4/27/2007 7:40 AM
"Say I want to model a chess opponent in REST. How do you do that in rest by modeling states?"

Post the move (or the entire board state) to the chess board. Plus, that's what distance chess players do more or less.
# re: I finally get REST. Wow.
Ittay
Posted @ 4/27/2007 8:12 AM
sorry if i wasn't clear. makeNextMove was referring to a computer opponent. so i ask it, what is its next move.

thinking of it, probably the RESTful manner would have been just to inquire the state of the whole board. but that doesn't look easy to work with.

my question (and point) is, say i have an application with a function like 'int foo(string, int, bool)' (meaning, a function that takes many arguments and returns some value). how can you model that in REST?
# re: I finally get REST. Wow.
Me
Posted @ 4/27/2007 8:25 AM
Ittay - If you don't have state in the endpoints, you would have to embed the complete state (chess position, e.g., in FEN notation) in the request.
# re: I finally get REST. Wow.
BradK
Posted @ 4/27/2007 9:38 AM
Two things:

- I've not seen any good aiuthentication mechanisms for REST. How do you use this in the real world enterprise, where you have to authenticate and authorize ?

- I both hate and love soap headers. But I can't deny their usefulness in practice (correlation ID's for messages, for example). Does this metadata concept not apply in REST ?
# re: I finally get REST. Wow.
Gordon Weakliem
Posted @ 4/27/2007 9:46 AM
Ittay - Tim's point is that it's really a different model. If you start by asking "how do I translate this RPC interface to REST?", you're approaching the problem the wrong way. It's more like the classic model for a filesystem, or device drivers.
I'm not very familiar with chess rules and I'm thinking about this model on the fly, but throwing out a guess at how I'd do it:

1) POST to the server to create a new game, saying which color the client is going to be. The server returns the URI of the "board"
2) GET the URI returned from the server at any time to get the current state of the board. You could optimize this by having POST return the current complete state of the board. If the server goes first, that state could be reflected in the first state, or you could have a separate operation on that URI to tell the server it's time to start play.
3) POST a move to the URI to ask the server for a state change (have the client make a move). Since chess is a synchronous protocol (players always alternate turns), you could have the server return its move in its response to the client. If the server will take a long time to think about its move, this obviously isn't a great idea; in that case you might poll the new board state with GET.

You said "probably the RESTful manner would have been just to inquire the state of the whole board" - how is that different from an RPC interface? My point is that you can do it either way - there's no rule that says you can't have the server respond to a client's state change request with its own declaration of state.
# re: I finally get REST. Wow.
Chris Parker
Posted @ 4/27/2007 10:48 AM
At the end of the day, this is like xml-rpc, but without the protocol and all of the nice libraries. It IS nice, but at the end of the day you are still sending requests back and forth as XML. I like the current XML-based RPC mechanisms.
# re: I finally get REST. Wow.
Andrew Wahbe
Posted @ 4/27/2007 10:59 AM
For what its worth, a conversation about this with a colleague yielded the following: if you think of the rules of chess to be the "protocol" then you can model the game states as documents identified by URIs. You GET a clean board with links for all possible moves (ya there's a lot but so what). You GET the appropriate link to make a move. The server applies both your move and the opponent's move and returns a new document with the board state and options. And so on.

The contrast with Joe's POST-based solution is very relevant to the article. With that solution the client has to know the rules of chess to construct a valid new board; with the link-based solution, it doesn't.
# re: I finally get REST. Wow.
Andrew Wahbe
Posted @ 4/27/2007 11:06 AM
Sorry it was Bill not Joe... wrong REST guru ;-)
# REST as State Machine - Duh!
David Van Couvering 's Blog
Posted @ 4/27/2007 11:26 AM
Tim Ewald get's the "aha" moment and shares it with the REST of us.
# re: I finally get REST. Wow.
mamund
Posted @ 4/27/2007 12:21 PM
i'm with you!

i've been spending the last few weeks implementing a base class httphandler that i use to implement http methods ala REST. i still have lots to do, but now i can create a new class that already has all it's methods ready for overriding for GET, POST, etc.

it's taken me some time to get my head around it, but i spend my time creating my uri/representation/method tables and then popping into the code to implement each http method for the URIs.

i'm finding it much more direct than SOAP and i'm enjoying the process quite a bit.
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:34 PM
Dennis,

Mark is right on the money. You want your state representation to include links. If you define your own XML format for the state, you can decide what syntax to use for representing them.

Tim-
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:36 PM
Brian,

I agree with Mark about the lack of a standard for endpoint descriptions. The risk, I think, is in doing something that doesn't reflect the dynamicism that this solution allows, e.g., it makes assumptions about URI formats that you later want to change, or the introduction of new possible states as a protocol changes, or whatever.

If people feel we must have such a language, then at the very least we should wait for several years while we get experience building this way and come to understand what we really want. That way we have some hope of avoiding the fate of WSDL.

Tim-
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:38 PM
Harold,

I looked at Joe's post at http://bitworking.org/news/How_to_create_a_REST_Protocol. I think it focuses too much on the entity-CRUD style. That is the protocol for some apps, including the original one for the Web. I worry that it heads people down a path where they think that's all REST is about.

Tim-
# re: I finally get REST. Wow.
Ittay
Posted @ 4/27/2007 12:39 PM
the thing is, when you write software, you use an RPC model. what bothers me about REST is that it is not only an API. it enforces you to change your programming model.

that is not to say i don't like it. i do, for its simplicity and self documentation (e.g., provide all moves as links), but there is a price you pay.
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:40 PM
Danny,

I like the EngineOfState. I have to avoid the semantic stuff you raise on the explanation page, though! :-)

Tim-
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:43 PM
BradK,

There are plenty of authentication/authorization mechanisms: basic, integrated, certs, SSL, SAML, encrypted payloads instead of pipes via a range of technologies, etc. There are headers and you can add your own. You can use cookies or your own solution for correlation. In short, just look at the Web for answers. The goal is to work the same way.

Tim-
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:49 PM
Ittay,

You can treat your Foo method as a very simple protocol and model it's state machine. You haven't started so your in no state. You move to a state where you are done and have the result. To move to that state, you operate on a URI, providing the data necessary to perform generate the new state, ie., the string, int and bool. Whether you do this with GET or POST is beside the point (which is not to say that it is not important!). What you get back is the completed state, the representation of which is an int.

Mechanically this may seem like an XML-RPC call, and in this simple protocol example derived from a method call, that shouldn't be a surprise. The big difference comes when the resultant state includes links to other states that you can then traverse. The RPC world doesn't typically do that, and that's really the difference in the models.
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 12:51 PM
Chris,

With all do respect, I very much disagree. I spent a long, long time thinking the same thing: that REST is really just either CRUD with entities or RPC by another name. It really is about transitioning between states via links embedded in them. It's true that you could build something really RESTian with xml-rpc (or even SOAP), but in practice people don't.

Tim-
# re: I finally get REST. Wow.
Ittay
Posted @ 4/27/2007 12:58 PM
Tim, if i understand you correctly, you say i have a URL like http://example.com/Foo and i POST to it with an xml containing the parameters, getting back either a URL whose GET returns the int value, or getting it back from the original POST. in any case, this is just a fancy wrapper for a function call.
# re: I finally get REST. Wow.
Tim
Posted @ 4/27/2007 2:19 PM
Ittay,

Of course it is, because what you started with was a simple protocol derived from a single function call. The difference comes when the protocol is multiple steps. I'll post one of the examples I've been using in my own thinking about this.

Tim-
# On programming models...
XML Nation
Posted @ 4/27/2007 3:04 PM
# re: I finally get REST. Wow.
Alan Dean
Posted @ 4/27/2007 5:05 PM
To BradK

Re: http://pluralsight.com/blogs/tewald/archive/2007/04/26/46984.aspx#47009

"I've not seen any good aiuthentication mechanisms for REST. How do you use this in the real world enterprise, where you have to authenticate and authorize ?"

You can use plain or digest http auth

"I both hate and love soap headers. But I can't deny their usefulness in practice (correlation ID's for messages, for example). Does this metadata concept not apply in REST ?"

Use HTTP Headers to elaborate metadata.
# re: I finally get REST. Wow.
Alan Dean
Posted @ 4/27/2007 5:08 PM
To Chris Parker

Re: http://pluralsight.com/blogs/tewald/archive/2007/04/26/46984.aspx#47012

"... but at the end of the day you are still sending requests back and forth as XML ..."

This is not correct. REST utilizes any MIME type, not just XML. It is your choice as publisher which MIME types that you choose to support.
# re: I finally get REST. Wow.
Hovhannes Tumanyan
Posted @ 4/27/2007 8:44 PM
Gentlemen,
With all due respect, I disagree with your interpretation of the REST. My understanding is that rest is not about data formats (XML vs. MIME) or state encoding.
From what I learned on the net, the key characteristic of REST-ful system is its lack of state. In restful architecture the state information, I believe, is to be submitted with the request. That relieves the server from responsibility of state information storage and association with context or "connection". REST allows development of connectionless systems. HTTP is a good example of REST architecture (if we exclude the POST from it).

The chess game example brought in this thread appears not to be REST based. It would be REST based if the state of the chess game, i.e. the color of the board, positioning of figures etc. would be submitted with each and every request. Then the server would be stateless and restful.
# Link Listing - April 27, 2007
Christopher Steen
Posted @ 4/27/2007 8:51 PM
When you think things are not possible: WCF duplex callbacks through NATs and firewalls - safe and secure...
# re: I finally get REST. Wow.
Stefan Tilkov
Posted @ 4/28/2007 1:32 AM
@Hovhannes: No, you've misunderstood REST -- the communication is supposed to be stateless, but that does not at all mean the server can't store any state. It just should expose it as resources.
# re: I finally get REST. Wow.
Chui
Posted @ 4/28/2007 4:43 AM
hmmm, any operations on REST resources can still happen in the wrong order anyway. REST wins when limiting verbs to commonly understood semantics beats reading up documentation on RPC signatures. REST is a nice subset of RPC, but when you need RPC you need RPC. There's no substitute.
# re: I finally get REST. Wow.
Hovhannes Tumanyan
Posted @ 4/28/2007 12:05 PM
Stefan: I have to disagree. REST properties such as reliability and scalability could
not be achieved if the server was stateless.
Reliability here implies the ability to recover from server failures. Imagine a cluster cluster that consists of two independent servers. If one fails, the other picks up the request and finishes processing. In stateful model the spare server needs the state information stored on the failed server in order to process the request.
Stateless, i.e. restful design allows request processing without state information. That simplifies the implementation to a significant degree since there is no need to store the state and synchronize across servers in the cluster.
The same logic applies to scalability -stateless system allows any server can pick up and process any request at arbitrary processing phase.
Roy Fielding explained the steteless requirement very well in the section 5.1.3
of the original REST paper http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
# re: I finally get REST. Wow.
Alex Blewitt
Posted @ 4/28/2007 4:06 PM
You should take a look at Restlet (www.restlet.org) if you want a Java API for dealing with REST that doesn't concern itself with specifics like Atom or HTTP.
# re: I finally get REST. Wow.
Tim
Posted @ 4/28/2007 6:34 PM
Hovhannes,

REST does not imply or require that servers to not store state. If it did, how would Amazon maintain your shopping cart or your list of previous orders? Clearly there is state there, and it isn't always shipped by the client as part of the request. To achieve scalability and reliability, individual server processes are typically stateless and leverage a shared database or other storage system so that information location is not tied to client connection. None of this violates the notions of REST.

Tim-
# re: I finally get REST. Wow.
Tim
Posted @ 4/28/2007 6:37 PM
Chui,

Yes, it's true, you can invoke state transitions in the wrong order if you set your mind to it. You can invoke non-existant transitions as well. But if you use transition links in your state payloads, it's definitely harder to get wrong *by accident*, which is the real problem with this facet of RPC. As to REST being a subset of RPC, I completely disagree.

Tim-
# re: I finally get REST. Wow.
Greg Hoover
Posted @ 4/28/2007 9:04 PM
Tim,
In response to the discussion thread with Chui,

I was thinking along the same lines as Chui, and I also agree with your response: "But if you use transition links in your state payloads, it's definitely harder to get wrong *by accident*"

I was coming from the perspective of how REST holds up in a multi-user environment where data concurrency is an issue. If it is the communication that is stateless and not the resource (i.e. we are not passing the entire state of the resource on which we are operating), it seems that contention for the same data could result... and providing a locking mechanism hardly seems stateless to me.

I guess part of the link returned to the client could include a "timestamp" value (like used in Sql Server) or some important attributes of the resource so that when that link is requested to the server, the server could compare the attributes sent against the current values in the resource to determine if the state transition is indeed still valid to perform.

What are your thoughts / experiences in this area?
# re: I finally get REST. Wow.
Bill de hOra
Posted @ 4/29/2007 7:04 AM
Ittay: "my question (and point) is, say i have an application with a function like 'int foo(string, int, bool)' (meaning, a function that takes many arguments and returns some value). how can you model that in REST?"

That's a heck of a lot different from a chessboard; you should at least acknowledge your first question was answered.

But let's assume you're not playing fetch me a rock. Then try to move past metasyntactic functions. What does foo do? is it a pure function? Or does it flip a bit in a database we don't know about? Does it log me in? Place an order? What?

You need to answer these questions because the most important thing is to figure out the actors and the state; the function interface is secondary. Once the state exchange is known and between who, you can choose a appropriate method.
# re: I finally get REST. Wow.
Hugo
Posted @ 4/29/2007 11:40 AM
Take the hardware analogue, and you get:

Actor (me), state (pushing in a PCI card) into a system is more relevant than:

Building the system (being able to push the card in).

WS, XML, REST and Web debates, and major vendors, pay all the bills in the world, yeah right..
# re: I finally get REST. Wow.
Hovhannes Tumanyan
Posted @ 4/29/2007 11:56 AM
Tim,
If the Amazon was implemented according to the REST paper, the client would have to accumulate the contents of the shopping cart and submit it with each and every request. Here is a quote from Fielding's REST paper to proof my point

.... each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3)

The inventory information at Amazon can be considered constant in the context of single request and therefore is not part of the session state.
That being said, I agree that there are examples of applications where the state information can't be stored on the client and submitted with requests. Such applications can't be made fully REST compliant. They can possibly separated into stateless and stateful parts, the stateful part being the shared database mentioned in your message or an equivalent mechanism. The session storage then will be REST-less.
I think that not storing the session state on server is the most important difference between REST and other architectures.
# re: I finally get REST. Wow.
Stefan Tilkov
Posted @ 4/29/2007 11:57 AM
Hovhannes, quoting from the REST dissertation's section that you quote: "Session state is therefore kept entirely on the client." - i.e. it says "Session state", not "State".
# re: I finally get REST. Wow.
Tim
Posted @ 4/29/2007 1:05 PM
Hovhannes,

I view the shopping process as browsing and putting things into the cart. That is made up of many sessions, perhaps months apart. During a session, one of the states the client transitions to is the "ok, it's in your cart state". Then the client continues. I don't see anything wrong with saying that at that point the server has modified its own state and that is no longer kept in the client.

More importantly, though, I don't see any use in whether or not something is *truly* RESTian. The value in all this to me is the approach to modeling a state machine with URIs and state with embedded link URIs. Beyond that, I use my knowledge of how the Web works to guide me. We can debate endlessly whether the Web is really RESTian. My sense is that it is RESTian enough to work really well, which is all I'm after for my own systems.

Tim-
# re: I finally get REST. Wow.
Hovhannes Tumanyan
Posted @ 4/29/2007 1:34 PM
Stefan,
I'm a bit confused... In the context of this discussion I was equating the state to the session state. It looks that you don't. Could you, please, explain the difference? I'd be very curious to get your perspective.

Thank you for being so patient.
# re: I finally get REST. Wow.
Chui Tey
Posted @ 4/29/2007 9:35 PM
Transition links is a nice pattern.
It's a lot more than the 4 verbs of REST though.
Transitions smacks me more of Wizards and Guided UI than random access. Procedure calls have similar equivalents with error messages like "CoInitializeEx must be called first"
# re: I finally get REST. Wow.
Hovhannes Tumanyan
Posted @ 4/29/2007 10:33 PM
Tim,
It looks that differences in the interpretation of the REST come from different vision of RESTian architecture advantages. If I understand correctly, you appreciate the ease of application state modeling with URI. I agree that is convenient. If convenience and ease of development are primary objectives, then the location of state information is indeed irrelevant. However, the location of state information storage becomes imporant if concurrency and error recovery are of a concern.

Storing the state information on the client simplifies implementation of highly available server architecture where requests are handled by multiple independent servers.
If state information is stored on the server, the spare server will need some means to retrieve the state from the primary (failed) server in order to be able to take over and process failed request. The need to develop such a mechanism is eliminated if the state is stoted in back end database shared across the servers. However, doing so just offsets the problem to the shoulders of database designers/developers. Shared DB back-end does not solve the problem conceptually.
Contrary to that inclusion of the state information with the request allows the spare server to pick up the failed request and process it since all the requied information is in the request. To me, that is an important advantage of REST architecture as I understand it.

Here is another use case where inclusion of the state information with the request can be helpful:

Imagine that you're shopping on Amazon and at some point in time want to send the contents of your shopping cart to friend. If Amazon was truly RESTian then you could just copy-/paste the URL and the query string of the GET request(assuming it was GET not a POST) and send it to the friend. He/she then could paste the link to the browser which would render the contents of your shopping cart. Today that is not possible, because Amazon shopping cart URL and query parameters contain just part of the state information, in fact, they have the pointers rather than the actual state information (contents of your cart).

Cheers,
Hovhannes
# re: I finally get REST. Wow.
Hovhannes Tumanyan
Posted @ 4/29/2007 11:32 PM
Inspired by Tim's and Stefan's comments I did a bit more reading in REST in order to better understand RESTian's perspective into statelessness. While doing the research I found the following quote on REST Wiki, which, I believe, explains ideas that I was communicating in this discussion, in much crispier and straightforward fashion (http://rest.blueoxen.net/cgi-bin/wiki.pl?RestInPlainEnglish#nid690):

Statelessness
Statelessness is the idea that any server for a resource should be able to handle any request from a client. It doesn't have to be the same server as the one who earlier requests went to. In REST we would provide authentication information with each request rather than expecting the server to already know who we are. We would expect that the same url would return the same data no matter the state of our cookies.

Statelessness means that we can replace one server with another if it fails or needs to be upgraded. It also means that we can perform load balancing between servers. Both of these things are possible even without statelessness, but are more costly and difficult.
# re: I finally get REST. Wow.
Greg Hoover
Posted @ 4/30/2007 2:13 AM
As I read through this discussion, I keep visualizing the REST applications being described here in terms of a Windows WF state-machine workflow where the http requests move the workflow from one state to another.

Like REST/http, WF also allows the same ability to "statelessly" process a series of requests across machine boundaries, etc...

This might be an extreme statement, but it seems to me that as the WF runtime becomes as widely deployed as IIS, we are on the verge of the opportunity for a whole new generation RESTful application development.
# re: I finally get REST. Wow.
Rastamafoo
Posted @ 5/1/2007 8:39 AM
A recent lawsuit against Microsoft for infringement against a patent (</a href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,826,744.PN.&OS=PN/6,826,744&RS=PN/6,826,744">US 6,826,744</a>) granted to VCSY offers a method for employing REST in an arbitrary manner.

I am offering this information because, while this patent demonstrates operating systems, applications and distributed computer frameworks; a sister patent (<a href="http://patft.uspto.gov/netacgi/nph-Parser?u=%2Fnetahtml%2Fsrchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=7076521.PN.&OS=PN/7076521&RS=PN/7076521">7,076,521</a>) provides an agent method of securing transactions and interfaces and facilitates REST operations.

I would suggest looking up the backgrounds on the folks who brought the inventions forward.

Given MSFT's announcement regarding SilverLight and various tools trickled out to build internet applications, I think a reading of just these two patents (there are more) will make everyone sit up and wonder what the heck is happening in the technology world. Looks to me like the SOAP bubble is bursting.
# re: I finally get REST. Wow.
Rastamafoo
Posted @ 5/1/2007 8:44 AM
Greg-
I do believe you are right. That spells trouble, however, for Microsoft.

The (Vertical Computer Systems (VCSY) patent 6,826,744 provides the framework for building fully stated deterministic virtual machines across arbitrary nodes using patent 7,076,521 as the node granules.

Microsoft delayed Vista and Apple delayed Leopard and the coincidental dates indicated they are being delayed because they can't go forward directly with their virtualization efforts.
# re: I finally get REST. Wow.
Pankaj
Posted @ 5/2/2007 10:25 AM
A very interesting blog.
I am inspired from Tim's heading "I finally get REST".
I am in that process and hopefully will be able to say soon. I can see lots of expert comments in this blog from the people about REST.
I have few basic questions about REST.
1) How REST can be useful in non-browser based application ?
2) How can someone discover REST web services, since REST doesn't have anything like WSDL(WSDL is an XML grammar for specifying a public interface for a Web service), which is for SOAP.
Thanks,
# re: I finally get REST. Wow.
rrodrigu3z
Posted @ 5/2/2007 11:59 AM
Hi, interesting post...
Ruby on Rails (http://rubyonrails.org) has very good support for building RESTful applications, it is just beautiful...

Take a look at http://tomayko.com/articles/2004/12/12/rest-to-my-wife. Very nice and funny explanation about REST.

Sorry about my english, I'm Venezuelan!

Saludos!
# REST is Gathering Momentum in and Around Microsoft
Peter Madziak's Musings on Software Architecture &
Posted @ 5/2/2007 10:02 PM
Wow, all in a matter of a very short time, we see: 1.) Visual Studio "Orcas" CTP released with improved
# I finally get REST. Wow.
Jason E. Shao
Posted @ 5/2/2007 10:25 PM
I finally get REST. Wow.

It’s depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again. I know SOAP is really an XML messaging protocol, you can do oneway async stuff, etc, e...
# re: I finally get REST. Wow.
Christopher Norton
Posted @ 5/3/2007 9:44 AM

"...You GET the appropriate link to make a move."

GET should not be used to change state. That is, GET should be side-effect free or <i>idempotent.</i> Multiple GET requests to the same URI should return the same state. That is not to say that the state cannot be changed by something else behind the scenes, for example a request for a weather URI should return the current forecast.

A REST chess game would be as simple as POSTing a move to a URI using the standard chess notation seen in the back of the newspaper, sending a "from" parameter and a "to" parameter. This changes the game state and the server responds with the current state of the board, perhaps rendered as an image, if you want to get fancy.

Another way to think of chess would be as a series of documents each depicting the game at a different moment. You could POST to a URI like:

http://10.0.0.1/games/chess/matches/2007/05/03/

And the server would return the entire state along with a "permalink" for the latest move, just like in the comments to this thread.

(Oh, and as for the comment about "Real World" authentication and authorization mechanisms for REST, look no further than your online bank for a nice example.)
# re: I finally get REST. Wow.
Christopher Norton
Posted @ 5/3/2007 9:59 AM

> 1) How REST can be useful in non-browser based application ?

REST can be useful in pretty much any distributed computing scenario. Need some data? GET it. Have some data you want to save? POST it. Machines can talk HTTP, too. That's what the whole web-services hype is about, no?

2) How can someone discover REST web services, since REST doesn't have anything like WSDL(WSDL is an XML grammar for specifying a public interface for a Web service), which is for SOAP.

That's the beauty: there is nothing to discover. REST is about keeping the number of verbs to a minimum to achieve truly loose coupling. Here are the methods for HTTP: GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT. Data are represented as URIs and you manipulate them using these methods.
# "It's just RESTing"
Mike Taulty's Blog
Posted @ 5/4/2007 4:14 AM
Sorry for the title, couldn't resist. I found this; "SOAP is Comatose But Not Officially Dead" followed...
# re: I finally get REST. Wow.
jason
Posted @ 5/7/2007 6:10 PM
wonder if you've considered RESTlets for your HTTP layer?
http://www.restlet.org/about/features
# re: I finally get REST. Wow.
Tim
Posted @ 5/8/2007 6:39 PM
Chris,

When I said you use GET to make a transition, I meant a transition in the protocol state machine. That doesn't change system state, just the current state of the client within the scope of the protocol state machine.

Tim-
# re: I finally get REST. Wow.
Tim
Posted @ 5/8/2007 6:42 PM
Hovhannes,

I understand the statelessness model from the perspective of the REST spec viz the ability to go to entirely independent servers. That said, almost all systems in practice go to servers that share a common backend to access shared system state. They may also use cookies to access client session state (or other information mapped to cookies). This does not comply entirely with the REST model, but I have no issue with that. Pragmatically, the Web model works really well, whether it fully conforms to Fielding or not.
# Don't drop the SOAP
Sean the Nonbeliever
Posted @ 5/10/2007 11:09 AM
So, there's been A LOT of talk from the Microsoft camp and elsewhere about the new importance of
# re: I finally get REST. Wow.
David A
Posted @ 5/17/2007 5:47 AM
"2) How can someone discover REST web services, since REST doesn't have anything like WSDL [...]
That's the beauty: there is nothing to discover. REST is about keeping the number of verbs to a minimum to achieve truly loose coupling. Here are the methods for HTTP: GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT. Data are represented as URIs and you manipulate them using these methods."

All true, but misses the point that bothers a lot of people - you can tell them the verbs, but they don't know the nouns:

How do I know what I can PUT to a particular URI? How do I know what to expect if I GET from a particular URI? For human, web-browser interactions, this needn't be a problem, because the page will (or should!) explain what to do in natural language. But where's the machine-understandable version?

One answer might be to say that there isn't one - there should be a human-readable description of how to use a REST service, and developers will have to use that. But the question does have to be answered - it's not true to claim that all you need is the verbs.
# re: I finally get REST. Wow.
Andrew Wahbe
Posted @ 5/29/2007 2:56 PM
Christopher Norton,

About GETing a link to make a move... I'm saying that the URI encodes the new board state after your move was made. i.e. you pick the link that represents the move you want to make and GET it. The state of the game is not on the server so you don't change the server state with the GET. The response to the GET contains the state of the board after the opponent made the move (here the computer is the opponent). The nice thing about this is that only legal moves are linked from each board. So the "protocol" (i.e. the rules of the game) is encoded in the hypermedia. The game state is the application state. So "Hypermedia as engine of application state" roughly translates to "Rules of Chess as engine of Game State" in this case.