REST API using POST instead of GET

 

Let's assume a service offers some funcionality that I can use like this: 

GET /service/function?param1=value1&param2=value2

Is it right to say that I can use it with a POST query? 

POST /service/function { param1 : value1, param2 : value2 }

Are these two queries the same? Can I use the second variant in any case or the documentation should explicitly say that I can use both GET and POST queries?

You can't use the API using POST or GET if they are not build to call using these methods separetly. Like if your API say 

/service/function?param1=value1&param2=value2

is accessed by using GET method. Then you can not call it using POST method if it is not specified as POST method by its creator. If you do that you may got 405 Method not allowed status.

Generally in POST method you need to send the content in body with specified format which is described in content-type header for ex. application/json for json data.

And after that the request body is gets deserialized at server end. So you need to pass the serialized data from the client and it is decided by the service developer.

But in general terms GET is used when server returns some data to the client and have not any impact on server whereas POST is used to create some resource on server. So generally it should not be same.

Just to review, REST has certain properties that a developer should follow in order to make it RESTful :

What is REST?

According to wikipedia:

The REST architectural style describes the following six constraints applied to the architecture, while leaving the implementation of the individual components free to design:

  • Client–server: Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable.
  • Stateless: The client–server communication is further constrained by no client context being stored on the server between requests.
  • Cacheable: Responses must, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests.
  • Layered system: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches.
  • Code on demand (optional): Servers can temporarily extend or customize the functionality of a client by the transfer of executable code.
  • Uniform interface: The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. (ie HTTP GET, POST, PUT, PATCH, DELETE)

    • What the verbs should do

    SO user Daniel Vasallo did a good job of laying out the responsibilities of these methods in the question Understanding REST: Verbs, error codes, and authentication :

    When dealing with a Collection URI like: http://example.com/resources/

    GET: List the members of the collection, complete with their member URIs for further navigation. For example, list all the cars for sale.

    PUT: Meaning defined as "replace the entire collection with another collection".

    POST: Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation.

    DELETE: Meaning defined as "delete the entire collection".

    So, to answer your question:

    Is it right to say that I can use it with a POST query? ...

    Are these two queries the same? Can I use the second variant in any case or the documentation should explicitly say that I can use both GET and POST queries?

    If you were writing a plain old RPC API call, they could technically interchangeable as long as the processing server side were no different between both calls. However, in order for the call to be RESTful, calling the endpoint via the GET method should have a distinct functionality (which is to get resource(s)) from the POST method (which is to create new resources).

    Side note: there is some debate out there about whether or not POST should also be allowed to be used to update resources... though i'm not commenting on that, I'm just telling you some people have an issue with that point.

    I use POST body for anything non-trivial and line-of-business apps for these reasons:

  • Security - If we use GET with query strings and https, the query strings can be saved in server logs and forwarded as referral links. Both of these are now visable by server/network admins and the next domain the user went to after leaving your app. So if we send a query containing confidential PII data such as a customer's name this may not be desired.
  • URL maximum length - Not a big issue, but some browsers have a limit on the length. So if we have several items in our url like query, paging, fields to return, etc....
  • Post is not cache by default. Some say caching is desired; however, how often is that exact same set of search criteria for that exact object for that exact customer going to occur before the cache times out anyway?

    • BTW, I also put the fields to return in my POST body as I may not wish to expose my field names. Security is like an onion; many layers and makes us cry!

    链接地址: http://www.djcxy.com/p/45344.html

    上一篇: 哪个惯例是“正确的”

    下一篇: REST API使用POST而不是GET