7 ms·

The "true spirit" of REST, to me, is that there's a certain set of things you can do when creating an API that will let you re-use the huge amount of

The "true spirit" of REST, to me, is that there's a certain set of things you can do when creating an API that will let you re-use the huge amount of HTTP middleware that's been written and get correct (and useful!) semantics from it. Caches (browser-, edge-, and server-side-), load balancers, forward- and reverse-proxies, application-layer firewalls, etc. will all "just work" for your software if you do REST correctly, and won't have any weird edge-cases. Doesn't that assume that the middleware also implements REST correctly? As the article points out, there are all too many HTTP libraries that only support GET and POST, not the more "esoteric" verbs like PUT and DELETE.

dragonwriter 10y ago
> Doesn't that assume that the middleware also implements REST correctly? It assumes that the middleware supports HTTP properly.
ianamartin 10y ago
Can you not imagine a REST-ful use case where the DELETE options should never work? Come on, person. I don' know about you, but I provide REST stuff where the only option is update.
jasonkostempski 10y ago
The article says "most client and server applications don’t support all verbs or response codes" which, in my experience, is not true. There are some but it's definitely not "most". For one, if you're writing both sides, don't build on client or server software that sucks. Sure, HTML forms don't support PUT and DELETE but how often to you use HTML forms instead of ajax requests (which do support those methods)? And, if you subscribe to a little bit of CQRS and Event Sourcing ideas, PUT and DELETE don't really make sense since you should really be POSTing commands to do those things. Where they do make sense is when manipulating files directly which I don't think comes up much these days.
naasking 10y ago
> As the article points out, there are all too many HTTP libraries that only support GET and POST, not the more "esoteric" verbs like PUT and DELETE. GET and POST are all you really need for REST.
- int_19h 10y ago
  What we really need is a set of verbs that allow to reliably distinguish between these three types of operations: 1. Pure read. 2. Impure (stateful) read. 3. Idempotent write. 4. Any other write. There's no particular reason to separate inserts, updates, deletes etc as part of the protocol - they're all just different kinds of writes, and middleware doesn't derive any benefit from being able to distinguish them. Thus, this can be a part of the payload. On the other hand, the difference between reads and writes, and the two subdivisions within each, do matter for purposes such as caching and automated error recovery (e.g. a proxy can repeat an idempotent write a few times before returning the error to the originator of the request). In REST, we have GET for #1 and #2, PUT and DELETE for #3, and POST for #4. In practice, this is often simplified to just POST used for both #3 and #4, but that loses a valuable distinction (but is unfortunately often necessary because of the lack of support for other methods). On the other hand, the PUT/DELETE distinction is largely pointless.
  - edoceo 10y ago
    PATCH verb? I've seen it in the wild
    - int_19h 10y ago
      Indeed, I forgot some. Then again, last time I tried to use PATCH, I found that support for it in various places in the stack was patchy enough to make it a non-starter.
  - naasking 10y ago
    It's not worth making the distinction between idempotent and non-idempotent writes given the possibility of network partitions. Every write must be made idempotent because all you can do is retry in this case. PUT is merely an optimization on idempotent POST requests, one that will become progressively rarer as HTTPS continues to spread. POST requests can be made idempotent by binding the result of processing that request to a future, so every subsequent request simply returns the already computed result. Impure reads are the default, and pure reads are designated by long-lived cache headers, ie. it's an impure read that lasts as long as the server responds. So really you just need GET and POST, and server-side frameworks should make POST requests idempotent by embedding some notion of futures for side-effecting operations. See the Waterken server for the first development platform to really get this right.
SEJeff 10y ago
Or (for REST apis that might need concurrent updates of the same model) the most awesome "esoteric" verb, PATCH
- Mikhail_Edoshin 10y ago
  Look into WebDAV and you'll find plenty :) LOCK, UNLOCK, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH. And also REPORT, SEARCH, and various version-control operations.
  - SEJeff 10y ago
    Oh sure, but the context is REST apis, not WebDAV :) PATCH allows two users to update different fields on the same resource at the same time with no conflicts. Otherwise, they'd use PUT and the last update would win unless they use something (client-side) such as compare and set.
pc86 10y ago
PUT and DELETE are just HTTP verbs and don't directly have anything to do with REST. You can support all verbs and have a garbage REST implementation, and (while obviously more difficult) have a great REST implementation for a handful of verbs.

dragonwriter 10y ago

> Doesn't that assume that the middleware also implements REST correctly? It assumes that the middleware supports HTTP properly.

ianamartin 10y ago

Can you not imagine a REST-ful use case where the DELETE options should never work? Come on, person. I don' know about you, but I provide REST stuff where the only option is update.

jasonkostempski 10y ago

The article says "most client and server applications don’t support all verbs or response codes" which, in my experience, is not true. There are some but it's definitely not "most". For one, if you're writing both sides, don't build on client or server software that sucks. Sure, HTML forms don't support PUT and DELETE but how often to you use HTML forms instead of ajax requests (which do support those methods)? And, if you subscribe to a little bit of CQRS and Event Sourcing ideas, PUT and DELETE don't really make sense since you should really be POSTing commands to do those things. Where they do make sense is when manipulating files directly which I don't think comes up much these days.

naasking 10y ago

> As the article points out, there are all too many HTTP libraries that only support GET and POST, not the more "esoteric" verbs like PUT and DELETE. GET and POST are all you really need for REST.

int_19h 10y ago
What we really need is a set of verbs that allow to reliably distinguish between these three types of operations: 1. Pure read. 2. Impure (stateful) read. 3. Idempotent write. 4. Any other write. There's no particular reason to separate inserts, updates, deletes etc as part of the protocol - they're all just different kinds of writes, and middleware doesn't derive any benefit from being able to distinguish them. Thus, this can be a part of the payload. On the other hand, the difference between reads and writes, and the two subdivisions within each, do matter for purposes such as caching and automated error recovery (e.g. a proxy can repeat an idempotent write a few times before returning the error to the originator of the request). In REST, we have GET for #1 and #2, PUT and DELETE for #3, and POST for #4. In practice, this is often simplified to just POST used for both #3 and #4, but that loses a valuable distinction (but is unfortunately often necessary because of the lack of support for other methods). On the other hand, the PUT/DELETE distinction is largely pointless.
- edoceo 10y ago
  PATCH verb? I've seen it in the wild
  - int_19h 10y ago
    Indeed, I forgot some. Then again, last time I tried to use PATCH, I found that support for it in various places in the stack was patchy enough to make it a non-starter.
- naasking 10y ago
  It's not worth making the distinction between idempotent and non-idempotent writes given the possibility of network partitions. Every write must be made idempotent because all you can do is retry in this case. PUT is merely an optimization on idempotent POST requests, one that will become progressively rarer as HTTPS continues to spread. POST requests can be made idempotent by binding the result of processing that request to a future, so every subsequent request simply returns the already computed result. Impure reads are the default, and pure reads are designated by long-lived cache headers, ie. it's an impure read that lasts as long as the server responds. So really you just need GET and POST, and server-side frameworks should make POST requests idempotent by embedding some notion of futures for side-effecting operations. See the Waterken server for the first development platform to really get this right.

SEJeff 10y ago

Or (for REST apis that might need concurrent updates of the same model) the most awesome "esoteric" verb, PATCH

Mikhail_Edoshin 10y ago
Look into WebDAV and you'll find plenty :) LOCK, UNLOCK, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH. And also REPORT, SEARCH, and various version-control operations.
- SEJeff 10y ago
  Oh sure, but the context is REST apis, not WebDAV :) PATCH allows two users to update different fields on the same resource at the same time with no conflicts. Otherwise, they'd use PUT and the last update would win unless they use something (client-side) such as compare and set.

pc86 10y ago

PUT and DELETE are just HTTP verbs and don't directly have anything to do with REST. You can support all verbs and have a garbage REST implementation, and (while obviously more difficult) have a great REST implementation for a handful of verbs.