4 ms·

Technically you can implement whatever you want under a `GET` - you can even stuff a body to a `GET` even though the RFC doesn't allow it (see ElasticSearch API

by yandie 4y ago

Technically you can implement whatever you want under a `GET` - you can even stuff a body to a `GET` even though the RFC doesn't allow it (see ElasticSearch API). However that doesn't mean it's a good implementation. What you're doing there is gonna break caching for example, unless that's intended. If I'm calling a `GET` and your service is behaving like a `POST`, I'm not gonna be able to rely on standard semantics for a lot of things!!!

pshirshov 4y ago
If you can't enforce a contract it's not a contract.
- BoorishBears 4y ago
  Maybe should learn what an RFC is, and check out this one before you keep trying to counter the document that formally minted the verbs in the first place: https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2 https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2 See section 9.1.2: Idempotent Methods, where they succinctly address the point: > Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. - It's funny, I wouldn't have thought the RFC needed to say this. I'd have thought it was a waste of words since it'd be obvious to absolutely anyone that you can't... what? magically force developers to not write a bit of code in a system you have literally no control over? Yet here we are, proving the authors well-prepared all these years later.
  - pshirshov 4y ago
    > Naturally, it is not possible to ensure that the server does not generate side-effects Of course it's possible, there are ways to guarantee that and to prove that. That's an area of ongoing research. E.g. https://link.springer.com/chapter/10.1007/978-3-642-36594-2_13 https://link.springer.com/chapter/10.1007/978-3-642-36594-2_... Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope.
    - ninthcat 4y ago
      It is not possible to prove that calling the server will not produce side effects. The link you provided does not address side effects, but correctness, which is much weaker. A trivial example is that calling the server will consume electricity.
      - pshirshov 4y ago
        "Side effect" is a breakage of referential transparency. Depending on your model it can be proven. Electricity consumption won't be a side effect in any reasonable model.
        notwedtm 4y ago
        What are you going on about? This feels like someone who's just read their first compsci book and now thinks they can build New Internet. Surely this is a troll...
        pshirshov 4y ago
        I'm saying that unenforceable contracts, like the "idempotence" of GET requests are no better than an annotation on a method in a conventional RPC IDL. If fact the latter is better, because it may be somehow enforced by cogen if you code-generate into a language which may, for example, enforce purity or totality. And the whole story about "REST not being an RPC" or "there is purity/idempotence/whatever in REST because RFC says that GETs are pure/idempotent/whatever" makes very little sense. At the same time I'm saying that it's total bullshit when someone says that it's not possible to enforce lack of side effects (like in referential transparency) during a remote call.
    - BoorishBears 4y ago
      SCC is so unrelated to anything even being remotely discussed, that it would be an insult to the term "orthogonal" to describe it as such. It's such an off-the-wall connection I can hardly refute it: it's like we're talking about toasters and you dived into talking about CRISPR because I said the word "crispy". If anything it'd imply you're not familiar with CRISPR or toasters. > Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope. I guess you should look up what it means to expect something. In the context of your sentence hope and expect are synonymous*, so maybe you meant you can't guarantee? And even ignoring that mistake, it's not really useful to say "You can't be sure something doesn't follow guidance, you can only expect it" because that's tautological. Guidance in and of itself doesn't have any way to assert direct influence on an implementation, that's why it's literally called guide·ance. *before you use that to dive into a grammatical diversion, that is not generally the case, only specifically in your use.
BoorishBears 4y ago
I saw a truly truly awful codebase get around the caching bit by appending a random string of bytes to the query string. If you're willing to ignore the rules you can get away with pretty awful stuff that no one should really need to account for in a general conversation.
- imiric 4y ago
  > I saw a truly truly awful codebase get around the caching bit by appending a random string of bytes to the query string. This is a common cache busting technique. Why is it a bad thing?
  - BoorishBears 4y ago
    Why do I get the impression this is a leading question... If you have the option between cache busting and just using the correct HTTP verb, please choose the latter. As to whether there was an option in this particular case, I think the fact I referred to it as a "truly truly awful codebase" should provide a hint.
  - talideon 4y ago
    The correct solution for cache busting is generally to put a low TTL on the resource in question. Adding random crap in the end is only good if you're dealing with utterly broken caches or your webserver does some tremendously stupid header rewriting. In my experience, when people resort to that, it's down to a lack of understanding of HTTP itself. YMMV, however.

by yandie 4y ago

pshirshov 4y ago

If you can't enforce a contract it's not a contract.

BoorishBears 4y ago
Maybe should learn what an RFC is, and check out this one before you keep trying to counter the document that formally minted the verbs in the first place: https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2 https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2 See section 9.1.2: Idempotent Methods, where they succinctly address the point: > Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. - It's funny, I wouldn't have thought the RFC needed to say this. I'd have thought it was a waste of words since it'd be obvious to absolutely anyone that you can't... what? magically force developers to not write a bit of code in a system you have literally no control over? Yet here we are, proving the authors well-prepared all these years later.
- pshirshov 4y ago
  > Naturally, it is not possible to ensure that the server does not generate side-effects Of course it's possible, there are ways to guarantee that and to prove that. That's an area of ongoing research. E.g. https://link.springer.com/chapter/10.1007/978-3-642-36594-2_13 https://link.springer.com/chapter/10.1007/978-3-642-36594-2_... Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope.
  - ninthcat 4y ago
    It is not possible to prove that calling the server will not produce side effects. The link you provided does not address side effects, but correctness, which is much weaker. A trivial example is that calling the server will consume electricity.
    - pshirshov 4y ago
      "Side effect" is a breakage of referential transparency. Depending on your model it can be proven. Electricity consumption won't be a side effect in any reasonable model.
      - notwedtm 4y ago
        What are you going on about? This feels like someone who's just read their first compsci book and now thinks they can build New Internet. Surely this is a troll...
        pshirshov 4y ago
        I'm saying that unenforceable contracts, like the "idempotence" of GET requests are no better than an annotation on a method in a conventional RPC IDL. If fact the latter is better, because it may be somehow enforced by cogen if you code-generate into a language which may, for example, enforce purity or totality. And the whole story about "REST not being an RPC" or "there is purity/idempotence/whatever in REST because RFC says that GETs are pure/idempotent/whatever" makes very little sense. At the same time I'm saying that it's total bullshit when someone says that it's not possible to enforce lack of side effects (like in referential transparency) during a remote call.
  - BoorishBears 4y ago
    SCC is so unrelated to anything even being remotely discussed, that it would be an insult to the term "orthogonal" to describe it as such. It's such an off-the-wall connection I can hardly refute it: it's like we're talking about toasters and you dived into talking about CRISPR because I said the word "crispy". If anything it'd imply you're not familiar with CRISPR or toasters. > Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope. I guess you should look up what it means to expect something. In the context of your sentence hope and expect are synonymous*, so maybe you meant you can't guarantee? And even ignoring that mistake, it's not really useful to say "You can't be sure something doesn't follow guidance, you can only expect it" because that's tautological. Guidance in and of itself doesn't have any way to assert direct influence on an implementation, that's why it's literally called guide·ance. *before you use that to dive into a grammatical diversion, that is not generally the case, only specifically in your use.

BoorishBears 4y ago

I saw a truly truly awful codebase get around the caching bit by appending a random string of bytes to the query string. If you're willing to ignore the rules you can get away with pretty awful stuff that no one should really need to account for in a general conversation.

imiric 4y ago
> I saw a truly truly awful codebase get around the caching bit by appending a random string of bytes to the query string. This is a common cache busting technique. Why is it a bad thing?
- BoorishBears 4y ago
  Why do I get the impression this is a leading question... If you have the option between cache busting and just using the correct HTTP verb, please choose the latter. As to whether there was an option in this particular case, I think the fact I referred to it as a "truly truly awful codebase" should provide a hint.
- talideon 4y ago
  The correct solution for cache busting is generally to put a low TTL on the resource in question. Adding random crap in the end is only good if you're dealing with utterly broken caches or your webserver does some tremendously stupid header rewriting. In my experience, when people resort to that, it's down to a lack of understanding of HTTP itself. YMMV, however.