Hypermedia Context

Descriptions of REST interfaces often use the notion of types when talking about the exposed resources. The Atom Publishing Protocol for example includes a section that provides a resource classification. Such classifications are not against the RESTfulness of an interface as long as the classes are expressed in terms of the knowledge a client has acquired about a resource. The Atom Publishing Protocol for example states that "a Resource whose IRI is listed in a Collection is called a Member Resource". This is a valid classification from the point of view of its RESTfulness.

In order to emphasize that such classification can only be done in terms of the acquired application state of the client I suggest the term "hypermedia context" instead of "classification". REST interface descriptions could then for example state: "The hypermedia context of a resource is called Member if its URI is listed in a collection". There is probably also value in distinguishing the client-acquired knowledge about a resource from the context used in the specification by calling the former acquired hypermedia context or just hypermedia context and the latter named hypermedia context.

I can also see possibilities to formalize hypermedia contexts along the lines of predicates, for example as an AND combination of known links, appearance of links in received hypermedia and (XPath-)matches on the representations of resources.

But I'll address that in a follow up.