I have a REST API that has been built on top (in front of) a legacy system, to allow 3rd parties of various platforms to interact with the system.

Most of the time, I can define a resource and create a GET and POST/PATCH etc. However, I have a couple of cases where the GET needs to be able to handle potentially a large about of request data, e.g. resource ids, too many for a query parameter.

Example api/books.

I need to be able both request data on existing books, and also add new books into the system.

So, I would normally have

GET api/books
POST api/books

The problems is I need to be able to support a (potentially) large number if ids to request objects with information about a subset of the books, more than can be included in a url as query parameters. Previously, in a case like this, I have (reluctantly) used a POST so I can send the request parameters in the body.

The problem here, is I already wanted to use the POST to add a new book.

A debate on how to handle this occurred today, and we though we may use

POST api/books (as the GET) PATCH api/books as the add

Also thought of POST api/books/get, but this just seems wrong (having a verb in the url).

Has anyone else had to address a similar situation, where you need to use the POST for the GET but still need to "POST" to the resource as well, or perhaps have any suggestions on a better way to do this than what is suggested above?

Thanks in advance for any help!

  • 1
    Maybe this is too subtle of a difference, but why not make POST api/book create a book record, and POST api/books be the GET method. (The difference being the "s" at the end.
    – neilsimp1
    Nov 20, 2018 at 14:03
  • Hmm, Interesting thought.... I wonder if the "s" would be too subtle and some consumers may miss it.
    – peterc
    Nov 21, 2018 at 0:30

1 Answer 1


I would personally use a different endpoint if you really don't think you can use a GET request. Are you hitting a technical limit or is it just ugly to you?

Either way, assuming you can't use a GET request, I would make a separate endpoint. like /api/search/book or similar. That way the point of the endpoint is extremely obvious. You could also use an UPDATE instead of POST, but I would just make an entirely separate endpoint if you're using request types for things they aren't designed for. That way you don't muddle the logic.

  • thanks for that suggestion. Yes, there cold be a real physical limit (thousands) Ok, or perhaps to make it "closer" to the resource, another option may be api/books/search (so search is nested under the book resource). So we are now ädding a "book search" resource.
    – peterc
    Nov 21, 2018 at 0:20
  • 1
    Google cloud used a similar scheme to this as outlined here. We are going adapt this, but still use the / rather than the :. As they explain They should only be used for functionality that cannot be easily expressed via standard methods. I feel this is a good pragmatic approach. Accept you need to do this sometimes rather than givin up and saying "The REST pattern does not work for me".
    – peterc
    Nov 22, 2018 at 1:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.