CODEWITHSUNDEEP
restapicurlgetslim
simhamed
simhamed

Reputation: 95

API REST : 414 Request-URI too long using GET

While there have been many topics related to this issue, I still couldn't find a solution to this problem.

I have a GET API REST call that can be very specific, example :

/v1/books?id=40,41,42,43,44,45,46,47...

However, I get a 414 Request-URI too long error sometimes because the list of ids is long.

I've read on every topic related to this problem that we have to use POST instead of GET when there are many parameters (instead of trying to change the max limit in apache, which I agree is not a good solution)

But I'm trying to fetch books, not create ones! REST API is very specific that POST is for creating new entries. And since I'm using Slim Framework, if I call a POST to fetch books, it'll be expecting different parameters to create a new book. Slim can't specify two different POST /v1/books as it'll always use the first one it finds, no matter the parameters you send... (I'll either be fetching or creating books, never both at the same time)

So, is there a solution somewhere to my problem ? I'm a bit surprised there's not a REST solution yet... Looked so hard, couldn't find anything...

Thanks in advance!

PS : I'm consuming this GET API using cURL/PHP, no JS/AJAX in there.

Upvotes: 5

Views: 10129

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57257

But I'm trying to fetch books, not create ones! REST API is very specific that POST is for creating new entries.

No, POST is for all sorts of things. See It is Okay to Use POST, by Roy T Fielding.

It isn’t RESTful to use POST for information retrieval when that information corresponds to a potential resource, because that usage prevents safe reusability and the network-effect of having a URI.

414 URI Too Long indicates that the target-uri in the request's start-line has tripped the server's arbitrary length limit. Since the server is the authority for its own resources, it gets to make that sort of decision for itself.

The idiomatically correct answer is to create a new resource; which is to say you POST your information to the server, and the server creates a new resource and a matching identifier. For example, the server could save the contents of your post into a random file name, and then send you back the information you wanted with an identifier that encodes that filename, so that you can GET any updates later.

POST /v1/books

id=40,41,42,43,44,45,46,47...

201 Created
Location: /v1/book-lists/9d133345-ded1-47ab-a954-a81c1d6d487f
Content-Location: /v1/book-lists/9d133345-ded1-47ab-a954-a81c1d6d487f

-- current representation of /v1/book-lists/9d133345-ded1-47ab-a954-a81c1d6d487f here --

Subsequent requests to see if the representation has changed could then be sent to the book-lists URI.

This is not, of course, free. Somebody has to decide that they want this in their domain application protocol, design the resources, implement the server side caching of the query payload, and so on.

Also, note that this doesn't actually solve the problem, being that the server should not be expected to support arbitrarily long (aka infinitely long) requests. It really only gives you some breathing room between the length that the server thinks is too long for a target-uri and the length that the server thinks is too long for a payload (413 Payload to Large).

So if you are designing an API, you need to think about what use cases you want to support, what data lengths are at the extremes of those use cases, and choose a domain application protocol that satisfies them, subject to your other constraints.

Upvotes: 3

Related Questions