For me personally, the two most important constraints for a legitimate ReST application are: - HATEOAS - registered mime-types In particular, the use of regis

For me personally, the two most important constraints for a legitimate ReST application are: - HATEOAS - registered mime-types In particular, the use of registered mime-types. An example: Say we are building a restful music service similar to Spotify. Say we focus on the list of as users playlists. We can embody the currently logged in users list of playlists as a resource with a specific URL. This URL is opaque to both the client and server. The representation of this list of playlists could be in the form of a Json hash where key is the playlist name and the value is the URL for the playlist itself. We also could declare that the following interactions are available to any client that receives this payload from a HTTP GET request: - Create a new playlist - delete a playlist And therefore we can fulfil the HATEOAS requirement. As I understand it, in order to make this restful we must register this as a custome media type as the additional actions we have defined are part of the available interactions with this media-type. Don't confuse the content of the representation with a definition of a media-type; we could declare our custom media-type as so: Application/vnd.spotify.com.list.playlists+Json It is the definition of the media type that dictates that the HATEOAS links in the header with the rel type of create or delete of how clients should interpret them. It is this media-type that dictates this. It is my understanding that pumping raw Json over http, even with HATEOAS in the headers (or even worse, with links embedded in the Json with the out of band knowledge that a client should interpret our key/value pairs as hypertext based only on the resource URL) is not in anyway restful.