4 ms·
No matter how long you think they can get, take care if you are going thru a load balancer - many, (those by Citrix come to mind) can mysteriously truncate URLs
by ojiikun 14y ago
No matter how long you think they can get, take care if you are going thru a load balancer - many, (those by Citrix come to mind) can mysteriously truncate URLs and cause all manner of weird bugs.
And, of course, insert here a long-winded rant about how broken your data model is if you need more than about 1000 chars. ;)
- afandian 14y agoWhat about lots of GET params? Doesn't seem like lots of those means you have a broken data model.
- mistercow 14y agoI think if you have nearly 1KB of GET data, something is definitely wrong.
- waitwhat 14y ago1KB of GET data is ~25 UUIDs. That doesn't seem excessive.
- mistercow 14y agoThat 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 agoEven 125 is not all that much if the resources are not being directly shown to the user (e.g. automated services, etc).
- mistercow 14y agoI'm trying to understand why you wouldn't use POST in that case.
- mnarayan01 14y agoIt'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 agoThe 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 agoThat'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 agoSure. All the proxies between you and the client are a lot more likely to cache a GET than a POST.
- mistercow 14y agoI'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.
- deleted 14y ago[deleted]