I was talking the other day about "scenarios" where you can (eventually) use REST in the enterprise, and how some of those scenarios will allow you to "loose" some of the constraints - and so some of the resulting properties of the system - while maintaining the "quality" of the system - basically that it fulfil its goals. That talk suggested me to come up with a "classification" of REST, not from the point of the REST constraints that a system follows [2][3][4] but from the point of view of the "scenarios" where it can be applied.
Coincidently, some hours after that I saw the blog post from Subbu Allamaraju [1] that somehow relates to what is REST or not, focusing more on the "quality attributes" than on the constraints, and I somehow related what could be a "group" of those "quality attributes" to what I called "scenarios". So I came up with this kind of a draft of a "classification" by "scenarios" that could eventually drive adoption of REST in some situations. Of course, the hard part is not here, to define exactly what constraints/properties you are dropping in each "scenario".
Level A: You have 100% control of the server, 0% (that's "zero") of the client. This will be the "common case of the web", level 3 of the "Richardson Maturity Model" [2][3], Jan Algermissen's "REST" in his "Classification of HTTP-based APIs" [4], just REST in the "purists" POV where everything else is deemed NOT REST (*)
Constraints you can relax/suppress: none
Properties that you are dropping: none
Level B: You have 100% control of the server and "little" control on the client. Let's say you are in a position where you can "influence" the client. This will be the case with business-partners, for instance.
Constraints you can relax/suppress: ?
Properties that you are dropping: ?
Level C: You have 100% control of the server and "some" significant control on the client. Let's say you are in a position where you can "negotiate" with the client until both reach a agreement, or even partially "impose" what you want. This will be the case with business clients, for instance.
Constraints you can relax/suppress: ?
Properties that you are dropping: ?
Level D: You have 100% control of the server and 100% control on the client. This will be the case with in-house development and deployment.
Constraints you can relax/suppress: ? - (all? but at what level of "dropping" constraints makes the application completely out of REST? - again without taking the "purist, "all-or-nothing" approach)
Properties that you are dropping: ?
So, in short, considering that you always have full control of the server
Level A: no control (of the clients)
Level B: influence
Level C: agreement
Level D: full control
Do you guys think this is worth defining, if it makes sense at all? Is anyone interested in picking this and try to define those constraints/properties that can be dropped in such scenarios. I must confess that I'm not completely at ease with my limited experience of REST to do such a task.
(*) which in my opinion is absolutely correct but not very useful in the "real" world of enterprise Applications. It reminds me of the engineer and the guy on a balloon joke.
[1] http://www.subbu.org/blog/2011/05/measuring-rest
[2] http://martinfowler.com/articles/richardsonMaturityModel.html
[3] http://www.crummy.com/writing/speaking/2008-QCon/act3.html
[4] http://www.nordsc.com/ext/classification_of_http_based_apis.html
