How to identify objects as REST Resources
Assuming the reader has an idea of the REST design philosophy, rampant confusion exists on what is exactly a resource. Much debate exists on how to identify and/or classify Internet HTTP objects as REST resources. A resource is the data end point of a URI (e.g., music.taliferro.com/artists/calima-shatiday/). Data is emphasized because REST resources should be a stateless data representations that can be bookmarked. It’s important to understand this design philosophy when creating a REST resource. This idiom is often ignored and puts a REST design in significant peril.
I have also seen many SOAP implementations shoe-horned into REST which only leads to abstruse REST structure.
So how are these resources manipulated? REST resources are manipulated in 2 ways, through the HTTP verbs (PUT=UPDATE, POST=ADD, GET=RETRIEVE, DELETE=DELETE) and custom REST objects called components.
Components act upon Resources. (What Roy Fielding calls components some people call controllers. REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.) This is an important concept to understand, because it is the foundation of good REST design.
A good REST design will define data elements as the resources, use PUT, POST, GET and DELETE to manipulate the data.
An easy way to design REST is to look at the landscape and divide your nouns and verbs. The nouns are your resources and the verbs should fit under PUT, POST, GET and DELETE and act as your controllers or actions verbs. If you can remember this simple design constraint, the limitation will assist in creating a decent REST design.