0

Problem Statment:

I need to pass a lot of parameters (say around 10) to an API that does some processing and returns some response. This particular API doesn't change the state of the system and guarantees that it will provide the same response all the time.

So, mostly, GET would be the go-to method for building this API. There are few technical and practical challenges in using GET method for this API. Once is there is limit on the number of parameters that can be passed in the URI and other one is, for the API client, it would be hard or confusing to build a request.

If I would go with POST to build this API, we can have client build a request in the form of JSON / XML and submit it in the payload and this way it would be easy to maintain and understand the client side code. But, technically, it's not appropriate to choose POST in this use case as the API doesn't modify the system state nor it's non idempotent.

Please suggest me with your views. Thanks.

Raj
  • 11
  • 1
  • If you already know that GET is not going to satisfy your needs then don't use it. You don't have to use REST as well. You can use some other standard, e.g. json-rpc (over POST) or create your own API. – freakish Aug 28 '16 at 18:57
  • 1
    Just because POST is not idempotent doesn't mean it HAS to change server state. – Adrien Aug 29 '16 at 10:08
  • @Adrien Agreed, but in a exception flow / state. In general, POST should be used for APIs which are not safe or not idempotent and the API in context is safe and idempotent. – Raj Aug 29 '16 at 18:01
  • personally I believe that idempotency is a bit of a myth anyway. Always some server state changes when any request is made (even if only changes to log file). enough web designers don't know about the concept so that they do change state on GET (especially when you're using it as an API with querystring arguments). So for me, it's just a convenience thing, POST can transfer larger amounts of argument data more reliably than querystring (which can be limited by intermediaries), and also has different cache interaction, since querystring is part of cache key. – Adrien Aug 30 '16 at 23:40

0 Answers0