This is a great description of *why* REST is so much better (at least, IMO)…
Two Cardinal Sins of REST API Design
Using a thing for its originally intended, “organic” purpose is ALWAYS better, in my experience, so it’s helpful to think about the central addressing scheme for the web and always keep in mind what it means!
U = Uniform (consistent to a standard… just good common sense)
R = Resource (this is a THING. we are addressing something, a noun)
I = Identifier (the unique identity of this thing)
L = Locator (the current residence for this thing)
Note that URI’s should NEVER change for a specific instance of this thing. URLs may change… though, hopefully, not frequently, as moving is always a p-i-a.
Now, following my own best practice of keeping the “things” in my solution as close to the original, organic “things” in my business problem space, take a look at the resource being addressed in a URI. Go pull a random URI for any of the code you’re working on today.
Is the URI pointing to a noun? Does the name of that noun exist within your business?
For example, if I go to the line of business and ask them to tell me what sorts of operations they typically perform on a “CustomerService”, what will they say? Nine times out of ten, they’re going to say, “Customer Service doesn’t have any operations… it’s one of the products we deliver to our customers!”
The resource isn’t a Service. Services are just verbs that have been crammed into a noun. SOA might be great for the Enterprise, but that’s a different topic. Individual applications should NOT be designed by the same design principles of SOA, that we use for the enterprise.
Change that previously mentioned “CustomerService” resource into a “Customer” resource and think about the difference it makes… especially, as you read this article.
This simple change will force you to be consistent about the canonical representation of your business objects, realign your functionality (i.e., operations) to your business objects (this alone, will either increase the business value of your solution, or will highlight the gaps in your object model), and make it easier to be consistent from one resource to the next.
Any thoughts or comments?