Re: ISSUE-31: Are Operations violating REST's uniform interface constraint?

Markus,

Just wanted to summarize this as this thread may be getting off-track a bit. I know Mark has bailed on this effort, but I believe he was trying to point out that even without hydra:status and hydra:returns, hydra:Operation still potentially violates the architectural constraints as it allows clients to potentially make assumptions about the behavior of the request which may or may not be true. I also agree with Mark to a certain degree. 

My point in this long thread was that if you need typed messages, it should be in the message itself rather than around the message. From my perspective, there’s little value in  having a CreateResourceOpertaion for a POST if the actual business function my application is carrying out doesn’t result in the creation of a new resource. Here’s two versions of the same message from beginning of this thread:

POST /my/cart/my/cart HTTP/1.1
Host: example.com
Content-Type: application/ld+json

{
    "@context": "http://example.com/cart",
    "@type": "AddItemToCartRequest",
    "productId": "1789",
    "productVarientId": "1641",
    "quantity": 2
}

and

POST /my/cart/my/cart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

productId=1789&productVarientId=1641&quantity=2

The main difference between the two examples is the media type being used. Functionally, they say the same thing. Without a doubt, the JSON-LD version is more descriptive, yet the application/x-www-form-urlencoded approach is in use on most sites today.  What makes the second approach “RESTful” is that the application/x-www-form-urlencoded request was generated from an HTML form. The browser was told what to do next by the current state of where they are now. That’s REST. It’s not about CRUD, it’s about describing links and and instructing clients on how to format and transmit those messages over the correct HTTP method at runtime. 

This is the role I was hoping that Hydra operations would play. But it seems that there’s also a belief that REST follows strict CRUD model, which just wrong. REST is not about using the uniform interface to enable CRUD. If you’re seeing both of the examples above as SOAP-like because they use a structured message format over POST to alter the state of other resources, then there is really not much more I can offer here. 

But if I’m mistaken and that your perspective is not that REST is CRUD and you don’t view POST as an anathema, then I may have a few suggestions. 


Ryan-

+-----------------------------------------------+
    Ryan J. McDonough
    http://damnhandy.com
    http://twitter.com/damnhandy