How to do REST right

Scott Raymond, works on BlinkSale

Had to stand for the first half of the talk so no notes. I’ll try to braindump them later. Hopefully the slides will be up, they are really good.

He started off with a discussion of what REST is and isn’t. Simply put, it isn’t the specifics of any given implementation (even HTTP) What it is is an “Architectural Style” so a level of abstraction above a specific architecture (like web architecture which in turn is above implementations like HTTP) but below straight communications theory. Simply put, I would describe REST as “the way the web is intended to work”. There are better discussions of what REST is and isn’t than I can provide elsewhere

How do I do partial updates? Essentially it’s a scoping issue. If all you want to do is update the first name for a person object that lives at http://site/person access it at http://site/person/first_name

I’m special; I need more than the GET/POST/etc semantics. - No you don’t. Anything can be modeled in this way. It may not be the best, but it works.

How should I do authentication? REST people generally frown on cookies. Normal auth is based on cookies. The problem is that application state now lives on the server. Individual requests aren’t self sufficient. This creates brittleness (can’t restart everything without dropping session information) hurts caching / replication. Next idea is HTTP Basic - problems: UI sucks, security sucks. HTTP digest: improves method, but sucks. Best of both worlds, put the session em in the cookie. Good UI, requests are still self sufficcient.

Should content type go in the url? last year the idea was that this is dirty. but if you do this then you can’t link. Rails is famous for being opiononated which is great with internal but not for UI. URLs are UI think for yourself. don’t blindly follow “the rails way” for UI.

Reliability in REST? Fans of SOAP will criticize this. Since 3 of 4 http methods are idempotent they are reliable. POST is a little harder. He does this by dividing POST into two steps. POST first to a factory method that gives you a new URL. Second phase POST to the new URL. If first request fails, you can keep trying until it succeeds. If you fail at the second phase you can post until it succeeds or you have a url you can test against. This is an imp;lementation of Two Phase Commit (here is an article I read a while ago talking about situations where it might be a good idea NOT to use two phase commit)

What about transactions? Same answer as the last one. This is really a scoping issue. Solution is to come up with a name for the specific transaction.

What about concurrency? Use some sort of etag??? that represents the current version of the resource so the server can detect and attempt to update a stale version of the resource and reject it

Multiple representations wit the same media type? Danger is that with you can’t add another representation. First look to use a specific, not generic media type. Hence, use atom not xml. Rails answer is to use a new URL

How do I do asynchronous ops like notifications? Polling is one way. But this is something that we need to put some information into. Register a URL to twitter event so that they post to that url. That way we don’t need to poll. That’s a really cool idea and shouldn’t be that difficult to implement.