Hacker News Reader

Hacker News

Comment by mistercow | Hacker News Reader

Parent Full thread

mistercow

I think if you have nearly 1KB of GET data, something is definitely wrong.

View on HN

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

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.

Even 125 is not all that much if the resources are not being directly shown to the user (e.g. automated services, etc).

I'm trying to understand why you wouldn't use POST in that case.

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

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.

Sure. All the proxies between you and the client are a lot more likely to cache a GET than a POST.

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.

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/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.

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).

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.

Wouldn't be RESTful.

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"?

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.

Reply on news.ycombinator.com