Monday, January 12, 2009

Websites are also RESTFul Web Services

This content has moved permanently to:
https://blog.jonm.dev/posts/websites-are-also-restful-web-services/

6 comments:

Mat said...

Rails has been really pushing this model since 2.0. It has a map.resource routing method that wires the rest CRUD to controller actions and even generates view helpers for restful links. And the make_resourceful plug-in can wire it to a DB model in just a few lines. Doesn't cover the category query though (yet).

Mat said...

I was thinking about this some more and question the use of '/items/-/{owner}joe@example.com' vs '/items?owner=joe@example.com'.

The GData category thing I can kind of understand, but why create a new (longer) syntax for what already exists?

Jon Moore said...

@Mat: It doesn't surprise me that there are frameworks that set up the boilerplate for this. If all your resources have Atom representations and support the same HTTP methods, there's going to be a lot of common code. Thanks for the links.

Regarding the query syntax, the GData spec does support the category query via query parameters; see the protocol reference for a little more discussion. In my mind, putting it in the URL signifies this as a different resource (Joe's items, rather than all items). But this is really just a matter of taste I think. The only thing I can think of is that some web caches do not cache requests with query parameters (this is Squid's default behavior, for example) so there might be some practical cachability impact.

digital id said...

I am a newbie in this field and thanks for sharing such an informative blog here i never knew that if we design a RESTful web site it is also a RESTful web API.now i can easily use and implement it in this way

Florian R. said...

Why did you chose a query parameter (format) for specifying the desired representation instead of using HTTPs built in functionality of content negotiation through the Accept and Content-Type headers?

Otherwise, I really like the idea of RESTful websites and thought about it a lot before stumbling over your post. Great primer!

Jon Moore said...

@Florian: If you read some of the discussions from the IETF HTTP Working Group, you'll find that there are many folks that think content negotiation was a bad idea in retrospect. Certainly it makes getting caching harder; your intervening caches must handle content variants correctly, and even then you have to make sure the server sets the Vary header properly. Using a query parameter instead is much more unambiguous.