Question

When you think about it, doesn’t the REST paradigm of being resource-oriented boil down to being object-oriented (with constrained functionality, leveraging HTTP as much as possible)?

I’m not necessarily saying it’s a bad thing, but rather that if they are essentially the same very similar then it becomes much easier to understand REST and the implications that such an architecture entails.

Update: Here are more specific details:

1. REST resources are equivalent to public classes. Private classes/resources are simply not exposed.
2. Resource state is equivalent to class public methods or fields. Private methods/fields/state is simply not exposed (this doesn’t mean it’s not there).
3. While it is certainly true that REST does not retain client-specific state across requests, it does retain resource state across all clients. Resources have state, the same way classes have state.
4. REST resources are are globally uniquely identified by a URI in the same way that server objects are globally uniquely identified by their database address, table name and primary key. Granted there isn’t (yet) a URI to represent this, but you can easily construct one.

Answer 1

REST is similar to OO in that they both model the world as entities that accept messages (i.e., methods) but beyond that they’re different.

Object orientation emphasizes encapsulation of state and opacity, using as many different methods necessary to operate on the state. REST is about transfer of (representation of) state and transparency. The number of methods used in REST is constrained and uniform across all resources. The closest to that in OOP is the ToString() method which is very roughly equivalent to an HTTP GET.

Object orientation is stateful–you refer to an object and can call methods on it while maintaining state within a session where the object is still in scope. REST is stateless–everything you want to do with a resource is specified in a single message and all you ever need to know regarding that message is sent back in a single response.

In object-orientation, there is no concept of universal object identity–objects either get identity from their memory address at any particular moment, a framework-specific UUID, or from a database key. In REST all resources are identified with a URI and don’t need to be instantiated or disposed–they always exist in the cloud unless the server responds with a 404 Not Found or 410 Gone, in whch case you know there’s no resource with that URI.

REST has guarantees of safety (e.g., a GET message won’t change state) and idempotence (e.g., a PUT request sent multiple times has same effect as just one time). Although some guidelines for particular object-oriented technologies have something to say about how certain constructs affect state, there really isn’t anything about object orientation that says anything about safety and idempotence.