0

I have a use case where some context needs to be transferred from the UI to the backend and backend needs to decide and send the response based on that context.

This can be achieved by sending the context through request body and at the server side, by parsing the request body, the representation can be sent in the response body.

My doubt is which http method is suitable for this?

GET: If we use GET, we can send the request body but it is advised that the body should not have any semantics related to the request. See this: http-get-with-request-body

So I am left with POST or PUT but these corresponds to updating or creating a resource and using them might be little misleading.

So my question is what is the appropriate HTTP method that could be used in this scenario which is acceptable in the RESTful design standpoint.

Appreciate the response.

I am thinking to use POST or PUT as there are no restrictions on consuming the request body on the server side.

EDIT:

I think POST would serve my purpose. The rfc HTTP RFC 7231 says that POST can be used for: Providing a block of data, such as the fields entered into an HTML form, to a data-handling process

So the data handling process for me is the backend server and HTML Form is equivalent to any UI element. So I can make use POST method to send the data to backend and send the existing resource representation as response body with http-status code being 200

Beatrix Kiddo
  • 57
  • 1
  • 6
  • Use Post method for same. – Sushil Mittal Apr 16 '19 at 08:40
  • Hey Ramakrishna! You recently asked this question and and I put time and effort to answer it. So I highly appreciate any [feedback](https://stackoverflow.com/help/someone-answers) in my [answer](https://stackoverflow.com/a/55704183/1426227). – cassiomolin May 21 '19 at 15:56
  • Hi cassiomolin. Sorry it a while to add a comment. I really appreciate your answer. It helped me lot. Thanks – Beatrix Kiddo Jun 24 '19 at 06:44

4 Answers4

1

Please bear in mind that GET must be used for data retrieval only, without side effects. That is, GET is both safe and idempotent (see more details here).

If the operation is meant to be idempotent, go for PUT:

4.3.4. PUT

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. [...]

Otherwise, go for POST, which is a catch all verb:

4.3.3. POST

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. [...]

cassiomolin
  • 101,346
  • 24
  • 214
  • 283
  • I think POST would serve my purpose. The rfc [link](https://tools.ietf.org/html/rfc7231#page-25) says that POST can be used for **Providing a block of data, such as the fields entered into an HTML form, to a data-handling process** – Beatrix Kiddo Apr 16 '19 at 08:58
  • @RamakrishnaShastri Indeed. It seems to be the most suitable method for your situation. – cassiomolin Apr 16 '19 at 09:24
0

I would go for POST because in REST, PUT is used to create a new resource like user.

Prateek Jain
  • 1,973
  • 2
  • 23
  • 37
  • Actually PUT operation is Idempotent. PUT is used to create if resource is not present else to update the resource. But anyway, thanks for the input – Beatrix Kiddo Apr 16 '19 at 08:46
0

There is a PATCH post method, that is for changing things maybe thats what you are looking for

Starmixcraft
  • 352
  • 1
  • 14
  • Actually I am not intending to change any resource, rather want to decide on what resource representation needs to be sent from the server side, based on request body. Resource already exists on the server side – Beatrix Kiddo Apr 16 '19 at 08:50
  • `CONNECT` is used to proxy by request, and since you send data depending on the request comming in, the `CONNECT` header my be the usefull – Starmixcraft Apr 16 '19 at 08:52
0

So my question is what is the appropriate HTTP method that could be used in this scenario which is acceptable in the RESTful design standpoint.

The world wide web is about as RESTful an example as you are going to find, and HTML forms only support GET (which should not have a request body) and POST. So POST must be fine (and it is).

More generally, POST can be used for anything; the other methods should be used when they are a better semantic fit. For example, you can use POST to make a resource unavailable, but DELETE is more explicit, and generic components can do sensible things because they recognize the semantics. PUT is a better choice than POST when what you are intending is to provide the server with a new representation of a resource, and so on.

I am not able to understand why the payload of the HTTP GET is forbidden

Payload of the HTTP GET is forbidden because the standard says "don't do that".

I believe it is written that way to simplify the rules for caching the response. As written, cache implementations only have to worry about header data (including information on the start-line).

But it could be as simple as the fact that the older versions of the standard didn't require that generic components do anything specific with the message-body of a GET request, and therefore modern specifications say "don't do that" in order to maintain backward compatibility. (One of the important constraints in designing long-lived systems is that you don't break older implementations.)

Community
  • 1
  • 1
VoiceOfUnreason
  • 40,245
  • 4
  • 34
  • 73
  • Thanks for the reply. But I am not able to understand whythe payload of the HTTP GET is forbidden have semantics of the request and even if it has it is forbidden to send the representation from the server side, based on that semantics. If you could shed some light on this, that would be great – Beatrix Kiddo Apr 17 '19 at 05:41