4 ms·

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind REST ended up with the term being used for everything.

bradleyjg 8y ago
At this point I guess any API that runs on top of HTTP is REST? Strange world.
- mbel 8y ago
  I guess REST became catch phrase for all JSON over HTTP protocols.
- u801e 8y ago
  I believe that one could make a REST API over other protocols like IMAP or NNTP.
cruegge 8y ago
They have an FAQ item concerning that: https://jmap.io/#why-is-it-not-rest-based https://jmap.io/#why-is-it-not-rest-based?
mariusmg 8y ago
Maybe unpopular opinion, but i'd take this any day over a "proper" REST api requiring DELETE and PUT. Also i'd classify a REST api as anything that does http requests and consumes proper JSON. As long as this is true , the rest is squabbling :)
- naasking 8y ago
  > i'd take this any day over a "proper" REST api requiring DELETE and PUT. REST doesn't need to use any HTTP verbs other than GET and POST.
  - rswail 8y ago
    REST doesn't need to use HTTP.
  - QasimK 8y ago
    As rswail said, REST doesn't need to use HTTP at all, however, if it does then it "should" use it fully including using HTTP headers for metadata. In theory, of course, you don't need anything other than POST
panic 8y ago
REST doesn't really have anything to do with the HTTP methods you use. It's about handing off state between the client and server using stateless requests instead of maintaining a persistent, stateful session. This blog post is a good overview: https://programmingisterrible.com/post/181841346708/what-the-hell-is-rest-anyway https://programmingisterrible.com/post/181841346708/what-the...
rswail 8y ago
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.
- pedrocr 8y ago
  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.
  - Twisol 8y ago
    > 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.
    - pedrocr 8y ago
      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.

bradleyjg 8y ago

At this point I guess any API that runs on top of HTTP is REST? Strange world.

mbel 8y ago
I guess REST became catch phrase for all JSON over HTTP protocols.
u801e 8y ago
I believe that one could make a REST API over other protocols like IMAP or NNTP.

cruegge 8y ago

They have an FAQ item concerning that: https://jmap.io/#why-is-it-not-rest-based https://jmap.io/#why-is-it-not-rest-based?

mariusmg 8y ago

Maybe unpopular opinion, but i'd take this any day over a "proper" REST api requiring DELETE and PUT. Also i'd classify a REST api as anything that does http requests and consumes proper JSON. As long as this is true , the rest is squabbling :)

naasking 8y ago
> i'd take this any day over a "proper" REST api requiring DELETE and PUT. REST doesn't need to use any HTTP verbs other than GET and POST.
- rswail 8y ago
  REST doesn't need to use HTTP.
- QasimK 8y ago
  As rswail said, REST doesn't need to use HTTP at all, however, if it does then it "should" use it fully including using HTTP headers for metadata. In theory, of course, you don't need anything other than POST

panic 8y ago

REST doesn't really have anything to do with the HTTP methods you use. It's about handing off state between the client and server using stateless requests instead of maintaining a persistent, stateful session. This blog post is a good overview: https://programmingisterrible.com/post/181841346708/what-the-hell-is-rest-anyway https://programmingisterrible.com/post/181841346708/what-the...

rswail 8y ago

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.

pedrocr 8y ago
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.
- Twisol 8y ago
  > 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.
  - pedrocr 8y ago
    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.