4 ms·

The choice between GET and POST should be driven by whether you're reading or modifying the resource, not the size of the request.

mistercow 14y ago
That's fine as an ideal, but can you give a non-aesthetic reason that it would actually matter? I can understand that for some APIs, it's cool that a human can read and edit the GET requests by hand and debug that way, but if we're talking about requests that pass around more than fifty UUIDs at a go, I don't think that's going to be a helpful approach anyway, and I'm really wondering if it isn't pushing the limits of a RESTful API to begin with.
- fusiongyro 14y ago
  Sure. All the proxies between you and the client are a lot more likely to cache a GET than a POST.
  - mistercow 14y ago
    I've never looked at the code for caching GET requests, but I am going to go out on a limb and say that that code is probably not optimized for keying on 1KB URLs. In fact, caching seems like a really good consideration regarding the original point about 1KB being too big for a GET request in terms of architecture design.
    - fusiongyro 14y ago
      You're really going to continue the debate by basically saying "I haven't read the code but it must not work like that?" In Squid it's 4K by default: http://www.squid-cache.org/mail-archive/squid-users/200208/0423.html http://www.squid-cache.org/mail-archive/squid-users/200208/0... I see no reference to a maximum URL size in Varnish, and a cursory glance through the source code is not revealing a hard-coded size. I'm not shocked. PHK is well-known for writing good code and good code generally doesn't have a lot of magic numbers. I really can't stand contrafactual arguing from first principles. I gave you a legitimate non-aesthetic reason and you came back with a softly wilted notion conjured whole out of your imagination. Shut up already.
- mnarayan01 14y ago
  You originally wrote: > I think if you have nearly 1KB of GET data, something is definitely wrong. The only point anyone is trying to make is that this is incorrect; retrieving multiple records is a perfectly good use case for having a URL that is more than 1KB (though there may be pragmatic reasons to avoid it).
  - mistercow 14y ago
    OK, that's a good point. I got off track with my argument, and started talking about practical alternatives, when I should have focused on 1KB being too much input for a read operation.

mistercow 14y ago

That's fine as an ideal, but can you give a non-aesthetic reason that it would actually matter? I can understand that for some APIs, it's cool that a human can read and edit the GET requests by hand and debug that way, but if we're talking about requests that pass around more than fifty UUIDs at a go, I don't think that's going to be a helpful approach anyway, and I'm really wondering if it isn't pushing the limits of a RESTful API to begin with.

fusiongyro 14y ago
Sure. All the proxies between you and the client are a lot more likely to cache a GET than a POST.
- mistercow 14y ago
  I've never looked at the code for caching GET requests, but I am going to go out on a limb and say that that code is probably not optimized for keying on 1KB URLs. In fact, caching seems like a really good consideration regarding the original point about 1KB being too big for a GET request in terms of architecture design.
  - fusiongyro 14y ago
    You're really going to continue the debate by basically saying "I haven't read the code but it must not work like that?" In Squid it's 4K by default: http://www.squid-cache.org/mail-archive/squid-users/200208/0423.html http://www.squid-cache.org/mail-archive/squid-users/200208/0... I see no reference to a maximum URL size in Varnish, and a cursory glance through the source code is not revealing a hard-coded size. I'm not shocked. PHK is well-known for writing good code and good code generally doesn't have a lot of magic numbers. I really can't stand contrafactual arguing from first principles. I gave you a legitimate non-aesthetic reason and you came back with a softly wilted notion conjured whole out of your imagination. Shut up already.
mnarayan01 14y ago
You originally wrote: > I think if you have nearly 1KB of GET data, something is definitely wrong. The only point anyone is trying to make is that this is incorrect; retrieving multiple records is a perfectly good use case for having a URL that is more than 1KB (though there may be pragmatic reasons to avoid it).
- mistercow 14y ago
  OK, that's a good point. I got off track with my argument, and started talking about practical alternatives, when I should have focused on 1KB being too much input for a read operation.