This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

RESTful Differences

Stefan Tilkov,

An excellent post by Benjamin Carlyle (on the REST-discuss group):

REST pushes unformity of verbs and message structure at the network level, and in fact forces us to rethink the application level significantly. If the uniform version works, why waste time inventing a more specific or type-safe version? Why validate the whole data structure down in some network stack when you can transport the raw data to where it is used and only process what is needed when it arrives? Why insist on converting a message into an intricate structure of data when you are just going to reencode it again for transmission or display it to a user? Why not just retain it as strings until you know what you will do with it?

On April 10, 2006 10:46 PM, ramtin said:

I value the passage where at zero state RPC and REST start converging. The REST representation however looks better. I need to handle the error condition anyway, regardless if it is thrown as an exception or represented as 404. I belief that the zero-state services are going to be introduced and also to be used. The fact that Googles translation service is not RESTFull does not mean that it is not USEfull.

On April 11, 2006 9:47 AM, Stefan Tilkov said:

Why do you think the translation service is not RESTful? Because it doesn’t access a stateful resource?

On April 11, 2006 11:43 AM, ramtin said:

according to benjamin yes :-)

snip .. This is not useful. The starting point for understanding a RESTful architecture is to think about the state that needs to be retained on the server side in order to keep things ticking along. In this case and cases like it, there is no server-side state. Because there is no server-side state, there are no server-side resources that need to exist to manage or delimit that state. …snap

On April 11, 2006 1:15 PM, Stefan Tilkov said:

I read the same comment and seem to understand it as the exact opposite. In cases where there is no server-side state (and I would say this applys to the Google translator), REST does not suggest you invent one. Only if there is state it should be modeled as stateful resources.

On April 11, 2006 4:03 PM, ramtin said:

ups! I skipped the part where the original author creates the artifical state by “/convert.cgi?format=pdf&document=mydocument.html”.