Skip to main content

Give it a REST

I'm wrapping up a REST layer to the service backend I've been developing for my still-unnamed-employer (find out when we launch, real soon now!). I had never developed a service under the "REST" acronym before, so my boss gave me a crash course, I read some things, I thought I got it. REST, a buzzword in its own right, is like stapling smoke to water when you try to define it. That isn't because its vague, its because most of the people who talk about it don't know what they're talking about.

Maybe I'm one of them and I shouldn't be posting this.

REST is Not:
  • HTTP
  • XML
  • RPC
  • A protocol, format, or even much of a specification
Rest is:
  • An idea(l)
  • Agnostic on just about every specification associated with it
Requests on a REST Service are:
  • Atomic. No request relies on any other made before or after it.
  • Self Authenticating. Every request must include any credentials. See point 1.
  • Self Describing. This is most commonly XML, and sometimes people think it must be, but it can be anything. We use JSON.
Some of the most interesting things I've learned working with a REST service are the things that do not fit the model well. No model fits every need perfectly, and REST doesn't escape that fact, I'm afraid.

In particular, you are not always transfering a state. There is a distinct difference between state transfer and a request to perform some operation upon a state. Unfortunately, any ways around some of the problems posed are directly rejected by the rules of REST.

For example, say you want to provide as a service a simple counter. You expose PUT on /counter/foobar to register a new counter, and then GET on /counter/foobar will provide the current level of the counter. Following the rules of REST, how do you provide an interface to safely increment such a counter? We can not perform a GET and a PUT, because it violates that each request be self contained, and it will break when any other client of the service is incrementing at the same time. We need a single operation to alter the state, without performing a state transfer.

The best thing you can do is use POST on a resource, and transfer a request to increment. It seems to violate the tenents of REST that the resource you POST will not actually reside at some permenant location, as they are throw-away requests. You either have to live with a not-exactly-REST interface (but, isn't that it works the important thing?) or actually keep requests around for some time. Maybe put them at some location, where they can be checked for review of their status.

I don't know if this is helpful to anyone else writing REST services, but the information around isn't always accurate, so why should I worry if I am?

Comments

Andrew Dalke said…
""""It seems to violate the tenents of REST that the resource you POST will not actually reside at some permenant location, as they are throw-away requests. """

That's not a tenent of REST. Think of submitting a blog entry. You POST to a resource which creates another URI (for the entry itself) and updates the main page.

For a counter you would not PUT at all, except perhaps to (re)set a counter. You could POST to a counter and have it increment by one, or GET from the counter to see its current state. Or use two URLs, one for each.

POST is a catch-all verb which has no explicit limitations on what it can do. GET should be side-effect free, PUT should only modify the resource PUT'ed to, and DELETE should only delete the resource PUT'ed do.

They can have side effect, eg, deleting an object likely means a resource listing all items in a collection gets updated. But the side effect should fit with the action.

POST, though, is free to do anything. Hence proxies and caches can't make any assumptions about its effect.
Jamie said…
Agreed... PUT is when you are placing (uploading) a resource to a pre-known location. Thus, /foobar/counter/1 would reset the counter to one. POSTing to a counter would increment it by one. If you were looking for a truly atomic "increment only if the current counter is less than 5" then you would use POST again.

Here's the basic difference: with RPC (i.e., XML-RPC, SOAP, etc), you call /getperson?name=jamie while with REST you'd call /person/jamie with a GET command.

In other words, with REST you call or create a resource -- a database record, an object in the OOP sense, the model -- with one of three basic VERBS, GET, PUT, or DELETE. (POST can be for RPC-like behavior when you don't actually know what the resource might be called.)

I.e., instead of calling a FUNCTION or METHOD and pass what object you want to call as a parameter, you instead call the remote object and pass the function (GET,PUT, DELETE) you want as the parameter.

It's actually not too hard, just requires an adjustment in thinking, but I agree -- most people that think they know what REST is, don't!

Popular posts from this blog

On Pruning Your Passions

We live in a hobby-rich world. There is no shortage of pastimes to grow a passion for. There is a shortage of one thing: time to indulge those passions. If you're someone who pours your heart into that one thing that makes your life worthwhile, that's a great deal. But, what if you've got no shortage of interests that draw your attention and you realize you will never have the time for all of them?

If I look at all the things I'd love to do with my life as a rose bush I'm tending, I realize that careful pruning is essential for the best outcome. This is a hard lesson to learn, because it can mean cutting beautiful flowers and watching the petals fall to the ground to wither. It has to be done.

I have a full time job that takes a lot of my mental energy. I have a wife and a son and family time is very important in my house. I try to read more, and I want to keep up with new developments in my career, and I'm trying to make time for simple, intentional relaxing t…

The Insidiousness of The Slow Solution

In software development, slow solutions can be worse than no progress at all. I'll even say its usually worse and if you find yourself making slow progress on a problem, consider stopping while you're a head.

Its easy to see why fast progress is better: either you solve the problem or you prove a proposed solution wrong and find a better one. Even a total standstill in pushing forward on a task or a bug or a request can force you to seek out new information or a second opinion.

Slow solutions, on the other hand, is kind of sneaky. Its insidious. Slow solution is related the Sunk Cost Fallacy, but maybe worse. Slow solutions have you constantly dripping more of your time, energy, and hope into a path that's still unproven, constantly digging a hole. Slow solutions are deceptive, because they still do offer real progress. It is hard to justify abandoning it or trying another route, because it is "working", technically.

We tend to romanticize the late night hacking…

Finding "One Game A Month"

I was really excited about the One Game A Month challenge as soon as I heard about it.
For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.
Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.
And it has worked.
I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games t…