REST is what Roy Fielding wrote about in his thesis. It is an architectural style, not a protocol.
It involves two endpoints exchanging the state of a shared resource. It needs to be compliant with the constraints of that style.
People think that REST must be over HTTP, but it can be over any protocol. The essence is that it is a style of systems design, so JMAP can be considered RESTful as described in the link above.
REST is one of the real patterns in software architecture, a set of constraints, not a set of structural elements.
I know all this, but this API doesn't meet that definition. As cruegge has linked the JMAP developers themselves don't consider their API REST. From the description it seems more like an RPC that's transaction oriented and for very good reasons.
The fact that this is a discussion though makes my point. By REST being only an achitecture style with very loose definitions makes it arguably fit for all different kinds of APIs which in turn has made the term useless over time. Maybe we could use a set of technical standards (like SOAP) for different common API implementation solutions within the bigger REST idea. Discussions like REST vs SOAP are like comparing OO and Haskell, one is a concept/pattern, another is a specific technology.
> As cruegge has linked the JMAP developers themselves don't consider their API REST.
That wasn't my takeaway. They don't consider it HTTP-based REST, but they do consider it RESTful. The FAQ's question is from the perspective of someone who doesn't make that distinction.
You can model things RESTfully, but the encoding of REST into a carrier protocol (commonly HTTP, but it doesn't have to be) is a separate matter. The "very loose definitions" largely stem from the encoding, not the modeling.
It's ambiguous indeed which again reinforces my point. The fact that you can issue several commands at once to be executed in order is strange for REST. And the REST definition also includes using common operations (GET/POST/PUT/etc if using HTTP) and this has invented it's own set that's specific to only this one API. So my read is that they're saying "we're actually more REST than a lot of things around but don't consider ourselves that".
>The "very loose definitions" largely stem from the encoding, not the modeling.
Sure, but the fact that we don't have strict definitions for common encodings means that you then have a discussion on it every time. It would be nice to have Standard A, that defines a common way to encode a common type of REST API (HTTP/JSON/etc) and we can just say our software uses that and REST is implied. Instead we get a situation where JSON-over-HTTP is perceived as being REST when it actually fails as a test in both ways. Some things are REST and don't use JSON or HTTP and some things are not REST and still use JSON and HTTP.
This is entirely fair -- I agree! REST isn't a protocol in the same sense that HTTP is. Although I believe a protocol's semantics and encodings should be distinguished a la REST, a way to talk about a particular encoding would be a very nice thing to have.
It involves two endpoints exchanging the state of a shared resource. It needs to be compliant with the constraints of that style.
People think that REST must be over HTTP, but it can be over any protocol. The essence is that it is a style of systems design, so JMAP can be considered RESTful as described in the link above.
REST is one of the real patterns in software architecture, a set of constraints, not a set of structural elements.