1

I am trying to develop a RESTful web service that will be used for entities like Users, Products, and the like.

To create new user I want to use

[POST] site/user

as REST specs say

However, I also want to search for users. According to REST specs that would be

[GET] site/user?name=Shuaib&city=Dhaka

So far so good. But what if I want to enter large JSON data as part of the search parameters? If I use get in that case -> my url will look clumsy -> since there is a restriction on GET request url size large JSON data might exceed url size

Because of these problems, I want to use POST for searching for user.

[POST] site/user

Is this a good development practice?

Shuaib
  • 779
  • 2
  • 13
  • 47
  • No. To create a new user call `[POST] site/user/create` – Nir Alfasi Nov 05 '13 at 08:54
  • 2
    But doesnt REST specs prefer `[POST] site/user` for creating a new user? – Shuaib Nov 05 '13 at 10:48
  • If you choose `[POST] site/user` to create a user then choose something else to `GET` a user. There is no spec (RFC) for REST AFAIK, but it's confusing (and hence a bad practice) to use the same URI for different services. It might also complicate testing! – Nir Alfasi Nov 05 '13 at 15:22
  • [This post](http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming) and its accepted answer seems to agree with @Shuaib. – atomman Nov 06 '13 at 01:07
  • 1
    Sorry, but that answer is terribly wrong, although that's what most people think REST means. URI semantics are irrelevant to REST. It encourages clear URIs, sure, but one or the other isn,t more or less RESTful. – Pedro Werneck Nov 06 '13 at 01:51
  • My problem is with searching users via POST. Actually I failed to explain my problem properly, so I have edited the question now. – Shuaib Nov 06 '13 at 03:36
  • If that's your real question, it's a duplicate. Check http://stackoverflow.com/questions/19771031/rest-request-cannot-be-encoded-for-get-url-too-long/19779354#19779354 – Pedro Werneck Nov 06 '13 at 11:00

1 Answers1

1

No. This is not a good development approach, especially if you are concerned with other developers using your API. If you can search with URI parameters, a developer might be surprised that he can submit a huge URI with lots of parameter and it still works, but there's no inconsistency or barrier to understanding in that.

On the other hand, if you make an operation standardized to GET to be made through a POST just because you don't want those huge URIs, then you have to document that, developers will have to be familiar with your decision, and this will be a problem for understanding.

Keep in mind that the HTTP standards don't establish any limits on URI size, so being huge in size shouldn't affect your API design decisions. Sure, almost 100% of the clients and servers are broken in some way and have some limit on URI size. If you actually hit that limit, the RESTful way to solve the problem is to use some workaround that's loosely coupled to your service and it's explicitly documented as a workaround to a broken implementation. For instance, a pre-processor that rewrites POST requests with a X-HTTP-Method-Override: GET header to a GET request, like it's done by the Google Translate API.

Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85
  • GET requests have limitations on URL size. Some search parameters might exceed that size so I was thinking of POST – Shuaib Nov 06 '13 at 03:19
  • GET requests don't have limitations on URI size. Broken implementations of HTTP do, and you shouldn't design around that. You should provide a workaround that isn't coupled to your design. – Pedro Werneck Nov 06 '13 at 11:00