January 25, 2010

REST Doesn't Lie

Have been reading about separation of concerns today and came to think that it might be interesting to shift the angle of looking at service evolution: Instead of asking what aspects of services might change it could actually be useful to ask whether there is anything that a service can guarantee not to change, no matter what future requirements it might encounter.

Shifting the point of view revealed a rest constraint that is probably so much taken for granted that it is not talked about very often:

"The only thing that is required to be static for a resource is the semantics of the mapping, since the semantics is what distinguishes one resource from another."

(Section Resources and Resource Identifiers of Roy's dissertation)

This is a guarantee the server has to make that is actually possible to adhere to because no evolution scenario of a server can possibly force it to change that mapping. The other two things that are not subject to change are (obviously) the uniform interface and the use of descriptive message semantics.

Besides these three aspects there is nothing in a networked system that servers can guarantee to clients and REST emphasizes that in an incredibly honest way. The client may depend on the above three aspects to remain true for the entire lifetime of a service but must plan for anything else to change.

What is the take-away? Two things mostly: you are not doing REST unless your system does not adhere to the above and you should exploit the stability of the resource semantics as much as possible in your service design.


  1. [...] REST Doesn’t Lie – Looking at what a REST service can guarantee not to change over the life of the service. (by Jan Algermissen) [...]

  2. "Two things mostly: you are not doing REST unless your system does not adhere to the above"

    I dunno if I read it that way, I read it as saying that all that is required to stay static is the mapping, not that its not RESTful to agree to keep more (relatively) static.

    In particular I'm not sure its always reasonable/possible to expect a client to plan for everything else to change.

  3. If the client does not expect to handle these changes then the server is coupled. REST aims to avoid that. If you introduce such coupling the server developer needs to get all client owners on the phone before making a change. The goal is to eliminate the need for such communication.