4 ms·

I continue to hold the crank opinion that http verbs are a useless spandrel. How much of a verb doing what the verb suggests it does is up to the developer? Th

I continue to hold the crank opinion that http verbs are a useless spandrel. How much of a verb doing what the verb suggests it does is up to the developer? The answer is 100%. Verbs provide no guarantees whatsoever, they're just an invisible thing that isn't in the URL. Why is something like that an invisible thing that isn't in the URL, with no specified behavior? Because it shouldn't exist is why.

themoonisachees 4y ago
Http status codes barely do anything to begin with nowadays. I was bombarded with them in college, and if you look at any webapp, it only ever responds 200, 302 or 500. Redirects are done in js, 404s are just normal pages, if that, and 401s are just not a thing on the public web anymore.
- quacksilver 4y ago
  I regularly see 401s and 403s on public APIs when interacting with them. 301s can be somewhat handy in certain circumstances too.
- delecti 4y ago
  I definitely use a bunch more than just those three, maybe as many as a dozen at various points. Probably another dozen occasionally leak through as problems from infrastructure we use. I could probably name several codes that I can't see much point in, but I'm sure people would respond why I'm wrong.
- capableweb 4y ago
  > Redirects are done in js Redirects definitely happen in more places than you think/see, mostly because almost all tooling handle redirects transparently to the user, so you don't really notice it. Doing redirects in JS is a huge waste of resources as well, as you'll need to load a full page with it's body (meaning the browser will parse and execute it) while having a 301 + Location header means the browser can redirect quicker without executing more stuff.
ume 4y ago
Not quite useless. POST tells the server to check for a body which I think is a reasonable indication of intent. But otherwise, yes, it’s all arbitrary and just vague hints to the server program as to what you might possibly be thinking of doing…
- Semaphor 4y ago
  But then GET as well as everything else can have a body, so most servers would check anyway.
  - jerf 4y ago
    GET isn't really supposed to have a body: "An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields." https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 (HTTP/2.0) "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 (HTTP/1.1) I've never used one or spec'd one, I consider it unsafe. This is, of course, what the specs say, and they don't even really agree; I am well aware of the non-trivial daylight between "what the specs say" and "what happens in the real world". I point this out not as a spec compliance maniac but as something people ought to know... it's not a great plan to expect GETs to be able to have bodies, just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. You're just asking for trouble, even if it might sometimes work.
    - vsnf 4y ago
      > just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. Do you mean to suggest that you advocate for an everything-is-200-OK design and the client should be checking for an error object there?
dnadler 4y ago
That's a fair criticism. On the other hand, I do find it useful to be able to construct an API where `PUT /object/1` will create an object, and `DELETE /object/1` will destroy it. It helps me keep things a bit more organized that way, but it wouldn't be hard to add the verb to the end of the URL instead. I would probably be in favor of some more strict guards around specific verbs, but I don't really know how that would be implemented given that the behavior is always controlled by the developer at the end of the day. Web frameworks adhering to these conventions is probably a good thing, though, and in my somewhat limited experience, that seems to generally be the case (though they often still let the developer override the behavior).
Ayesh 4y ago
Browsers behave differently based on the HTTP method, though. For example, POST requests are confirmed when trying to refresh, they are not cached, and a whole bunch of restrictions on XHR/fetch.
ThePadawan 4y ago
It's my understanding that a lot of early design decision like HTTP verbs happened due to the much wider spread of proxies.
svieira 4y ago
It's not about the "end user" developer of the server, it's about the middleware and the clients. A browser (for example) will happily retry a GET request that times out, but will not automatically retry a POST request that does the same. Will that break a badly behaved web API? Yes. But that's like saying that "calling conventions are a useless spandrel because the consuming code can ignore the convention and just read from arbitrary memory".
- samatman 4y ago
  That's actually a good example, because if the standard specified that POST must be idempotent, and that a POST without a uuid is invalid, we might have something here. Instead there's a workaround for a serious problem, and any client (browser being by no means the only client) which doesn't respect the convention can emit identical POSTs, with no way of knowing if that was intended.
  - svieira 4y ago
    The standard says "POST means NOT-IDEMPOTENT" and "clients MUST not re-issue a non-idempotent requests" and the client behavior naturally falls out of those two constraints.
    - samatman 4y ago
      The standard being completely backward and impossible to enforce is a problem!
      - P5fRxh5kUvp2th 4y ago
        standards are agreements, they've never been there with the expectation of enforcement.
        samatman 4y ago
        Unenforceable and unenforced are very different things.
cush 4y ago
But there are many guarantees browsers impose. The verb is incredibly important.
tenebrisalietum 4y ago
Well by that notion, all command-line executables should be stripped of their names and referred to by UUID, and any text-to-UUID mapping be the sole responsibility of the user.

themoonisachees 4y ago

Http status codes barely do anything to begin with nowadays. I was bombarded with them in college, and if you look at any webapp, it only ever responds 200, 302 or 500. Redirects are done in js, 404s are just normal pages, if that, and 401s are just not a thing on the public web anymore.

quacksilver 4y ago
I regularly see 401s and 403s on public APIs when interacting with them. 301s can be somewhat handy in certain circumstances too.
delecti 4y ago
I definitely use a bunch more than just those three, maybe as many as a dozen at various points. Probably another dozen occasionally leak through as problems from infrastructure we use. I could probably name several codes that I can't see much point in, but I'm sure people would respond why I'm wrong.
capableweb 4y ago
> Redirects are done in js Redirects definitely happen in more places than you think/see, mostly because almost all tooling handle redirects transparently to the user, so you don't really notice it. Doing redirects in JS is a huge waste of resources as well, as you'll need to load a full page with it's body (meaning the browser will parse and execute it) while having a 301 + Location header means the browser can redirect quicker without executing more stuff.

ume 4y ago

Not quite useless. POST tells the server to check for a body which I think is a reasonable indication of intent. But otherwise, yes, it’s all arbitrary and just vague hints to the server program as to what you might possibly be thinking of doing…

Semaphor 4y ago
But then GET as well as everything else can have a body, so most servers would check anyway.
- jerf 4y ago
  GET isn't really supposed to have a body: "An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields." https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 (HTTP/2.0) "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 (HTTP/1.1) I've never used one or spec'd one, I consider it unsafe. This is, of course, what the specs say, and they don't even really agree; I am well aware of the non-trivial daylight between "what the specs say" and "what happens in the real world". I point this out not as a spec compliance maniac but as something people ought to know... it's not a great plan to expect GETs to be able to have bodies, just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. You're just asking for trouble, even if it might sometimes work.
  - vsnf 4y ago
    > just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. Do you mean to suggest that you advocate for an everything-is-200-OK design and the client should be checking for an error object there?

dnadler 4y ago

That's a fair criticism. On the other hand, I do find it useful to be able to construct an API where `PUT /object/1` will create an object, and `DELETE /object/1` will destroy it. It helps me keep things a bit more organized that way, but it wouldn't be hard to add the verb to the end of the URL instead. I would probably be in favor of some more strict guards around specific verbs, but I don't really know how that would be implemented given that the behavior is always controlled by the developer at the end of the day. Web frameworks adhering to these conventions is probably a good thing, though, and in my somewhat limited experience, that seems to generally be the case (though they often still let the developer override the behavior).

Ayesh 4y ago

Browsers behave differently based on the HTTP method, though. For example, POST requests are confirmed when trying to refresh, they are not cached, and a whole bunch of restrictions on XHR/fetch.

ThePadawan 4y ago

It's my understanding that a lot of early design decision like HTTP verbs happened due to the much wider spread of proxies.

svieira 4y ago

It's not about the "end user" developer of the server, it's about the middleware and the clients. A browser (for example) will happily retry a GET request that times out, but will not automatically retry a POST request that does the same. Will that break a badly behaved web API? Yes. But that's like saying that "calling conventions are a useless spandrel because the consuming code can ignore the convention and just read from arbitrary memory".

samatman 4y ago
That's actually a good example, because if the standard specified that POST must be idempotent, and that a POST without a uuid is invalid, we might have something here. Instead there's a workaround for a serious problem, and any client (browser being by no means the only client) which doesn't respect the convention can emit identical POSTs, with no way of knowing if that was intended.
- svieira 4y ago
  The standard says "POST means NOT-IDEMPOTENT" and "clients MUST not re-issue a non-idempotent requests" and the client behavior naturally falls out of those two constraints.
  - samatman 4y ago
    The standard being completely backward and impossible to enforce is a problem!
    - P5fRxh5kUvp2th 4y ago
      standards are agreements, they've never been there with the expectation of enforcement.
      - samatman 4y ago
        Unenforceable and unenforced are very different things.

cush 4y ago

But there are many guarantees browsers impose. The verb is incredibly important.

tenebrisalietum 4y ago

Well by that notion, all command-line executables should be stripped of their names and referred to by UUID, and any text-to-UUID mapping be the sole responsibility of the user.