NBT consulting have published the details of a presentation called "REST Web Services with Spring MVC". Herein some comments on what looked liked an interesting presentation.

"GET-ful REST

• also called "Popular REST"
• GET may alter the resource (data)
• not recommended

"

Indeed it's not recommended! But this isn't "Popular REST", this is RPC tunneling. If you're using GET to change state, you're not working in the REST style as it appears in HTTP.

"Usually the id for the student is embedded somewhere in the URL path"

This is not an architecture thing, but please don't use primary keys in URLs. Doing so fails to encapsulate the implementation details of the software/persistence from the web; pks aren't a basis for stable URLs. For a few years now I've tended to giving entities something like an hash or a write-once "slug" that is an indexed natural key but not the database primary key; the hash can be used by the server to generate the resource URL. From the OO/DB perspective they seem redundant and I have been called up on them in the past - at the level of a single system's internals it seems pointless to have this extra key. But from the Web/Domain perspective they give a lot of value. Once exception might to this might be an admin/management console that is specific to the implementation (ie much of the reason it works because it knows your objects and data have primary keys); there it's possibly ok to expose pks.

"

• Is POST or PUT used to add a new resource?
• Is POST or PUT used to update a resource?

"

Described as controvesial questions, but they're not. Honest :)

Creation. You can use PUT or POST to create. If you use PUT, the client can know the final state of the created resource, but you give the client some control over the server's URL space, which might not always be appropriate. If you use POST the server has complete control over the resource URL, but the client won't immediately know that state of the created resource (POST semantics don't supply that information). Atompub uses POST, as it sees the server as the owner of URLs;  Atompub has use cases for multi-user single host environments like weblogs. WebDAV will let you use PUT to create, perhaps because of its roots in file systems (and for example that makes WebDAV a good idea for Subversion).

Update: You can use PUT or POST to update. As above, the issue is that POST does not provide information on the final state of the resource POSTed to, but PUT will. That the HTML forms specification and most technolgies that acquired their model from it (including imo much of WS-*), only allow GET and POST simply means they're broken as designed. A lot of people over the years have concluded as a result that POST is the prime method in HTTP; in fact it's merely the least specific. I think once you have PUT at your disposal, you will not want to go back to overloading POST for updates.

"Some REST practitioners say, you should embed the version of the Web Service in the URL path"

I think this depends on how you want to model your service over time. When you "version" a service, do you have two services or one service? The question is difficult :) if you dig down into WS-* versioning, you'll tend see the WS architects made policy decisions about how to model services that support one versioning option or another. Such policies don't exist in REST and that's probably ok.

"Can two different URLs control the same resource?"

This is tougher. Another way to ask it, is can a resource have two URLs? For the Web, the answer is yes, but only the authorities for the URLs can make that commitement. To state the claim in a 'machine readable' way, the URL owner(s) can use owl:SameAs. As with modelling for versioning, the fundamental issue, to do with naming, is a non-trivial one.

I would have liked to have seen the presentation, especially as it was focused on SpringMVC, which can support custom URL resolvers.  The code examples further down in the page are an interesting mix of method objects (eg PutMethod) and URL patterns in the bean mappings. Jerry Kiely and I concluded a while back that SpringMVC is up to the job of REST based applications; it's good to see this being fleshed out. Jerry was interested in embedding RESTlet and for me, one of the big downsides of working with Java frameworks is the intrinsically weak mapping between URLs and code. RESTlet and Paul Sandoz' Jersey are good examples that tackle the problem, but it would be nice to have to strong support for flexible URL to code mapping across the board.