Explain how operations dependent on a resource's state can be described

[lanthaler]

_This was raised a couple of times, most recently by James Langley:_

[...] we want the API to change behaviour at runtime depending on the current server state, i.e. a Class should be POSTable sometimes but not alway;, or a POST may return one Class in some circumstances, and another Class at other times (and the two Classes are not both semantically subclasses of the same super Class). A static Hydra context doesn't allow this. (We have been thinking about serving different Hydra contexts at different times to get round this, but I'm not convinced taht's a god way to go.)

[lanthaler]

That's something we discussed in the context of authorization in the past, see issue #7. The general approach would be to either define a property or a class that you include/exclude based on the resource state. Something like

{
  "@id": "just-an-entity",
  "@type": [ "BlogPost", "PublishedBlogPost" ],
  "comments": "just-an-entity/comments"
}

In this case, the operations that are supported on all posts are associated to the BlogPost class. The operations only applicable to published posts are associated to the PublishedBlogPost class. Similarly, the comments property is just included on posts that can be commented on.

[lanthaler]

PROPOSAL: This can be achieved by either including operation directly in the resource's representation or by using specialized subclasses that convey the resource's current state. Describe both approaches in the specification.