3 ms·

1KB of GET data is ~25 UUIDs. That doesn't seem excessive.

by waitwhat 14y ago

mistercow 14y ago
That seems like a lot of UUIDs to be passing via GET. If you send your UUIDs in base 64, you can fit 125 into 1KB.
- mnarayan01 14y ago
  Even 125 is not all that much if the resources are not being directly shown to the user (e.g. automated services, etc).
  - mistercow 14y ago
    I'm trying to understand why you wouldn't use POST in that case.
    - mnarayan01 14y ago
      It's certainly not an insurmountable problem; PUT or POST (or even a non-compliant GET) can be used to get around it. Those methods will only work, however, if the app developer anticipated the need for a high number of parameters.
    - fusiongyro 14y ago
      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.
    - MatthewPhillips 14y ago
      Wouldn't be RESTful.
      - mistercow 14y ago
        Yes, but for the current clients (and proxies) in the wild, and under the specific circumstances in question, REST is is a broken architectural style. Fundamentally, the purpose of a RESTful API is to have a standard organization of operations so that REST-familiar users automatically understand the general flow of the interface. The matter of specifying the CRUD operation via HTTP methods or via a separate parameter is an implementation detail. Is anyone seriously going to trip on your interface if you say something like "This API is essentially RESTful, but everything goes through POST and the CRUD operation is specified by the "op" POST parameter"?
        MatthewPhillips 14y ago
        I don't have a strong opinion on whether that's a good way to do it or not, but it's definitely not RESTful. The question I would have is whether it is ok to put your GET parameters in the body, which is generally frowned upon, but might be acceptable in this extreme circumstance.
  - deleted 14y ago
    [deleted]

1KB of GET data is ~25 UUIDs. That doesn't seem excessive.

mistercow 14y ago

That seems like a lot of UUIDs to be passing via GET. If you send your UUIDs in base 64, you can fit 125 into 1KB.

mnarayan01 14y ago
Even 125 is not all that much if the resources are not being directly shown to the user (e.g. automated services, etc).
- mistercow 14y ago
  I'm trying to understand why you wouldn't use POST in that case.
  - mnarayan01 14y ago
    It's certainly not an insurmountable problem; PUT or POST (or even a non-compliant GET) can be used to get around it. Those methods will only work, however, if the app developer anticipated the need for a high number of parameters.
  - fusiongyro 14y ago
    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.
  - MatthewPhillips 14y ago
    Wouldn't be RESTful.
    - mistercow 14y ago
      Yes, but for the current clients (and proxies) in the wild, and under the specific circumstances in question, REST is is a broken architectural style. Fundamentally, the purpose of a RESTful API is to have a standard organization of operations so that REST-familiar users automatically understand the general flow of the interface. The matter of specifying the CRUD operation via HTTP methods or via a separate parameter is an implementation detail. Is anyone seriously going to trip on your interface if you say something like "This API is essentially RESTful, but everything goes through POST and the CRUD operation is specified by the "op" POST parameter"?
      - MatthewPhillips 14y ago
        I don't have a strong opinion on whether that's a good way to do it or not, but it's definitely not RESTful. The question I would have is whether it is ok to put your GET parameters in the body, which is generally frowned upon, but might be acceptable in this extreme circumstance.
- deleted 14y ago
  [deleted]