Skip to main content
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

is it really that bad NOT to return a created resource ... in the same format it is POSTED?

HTTP actually gives you a lot of freedom in how you respond to messages.

For example, the section that specifies the 200 OK response code200 OK response code describes the kind of representations you might see in the response body.

POST a representation of the status of, or results obtained from, the action;

"representation of the status of the action could just be

Congratulations! we created a resource.

There's nothing in the semantics of the operation that says you must return a representation of the resource created.

Even if you don't buy that argument....

in the same format it is POSTED?

The Ur-example of a REST application is the world wide web. We download a form, fill it in, and submit. In most cases, the contents of the form travel to the server as an application/x-www-form-urlencoded collection of key value pairs. How often do you get one of those back from the server? Never, or some close approximation to, because the responses come back in text/html (or some similar variant).

If your "pragmatic approach" can point to a precedent on the world-wide-web, you are likely to be on solid ground.

is it really that bad NOT to return a created resource ... in the same format it is POSTED?

HTTP actually gives you a lot of freedom in how you respond to messages.

For example, the section that specifies the 200 OK response code describes the kind of representations you might see in the response body.

POST a representation of the status of, or results obtained from, the action;

"representation of the status of the action could just be

Congratulations! we created a resource.

There's nothing in the semantics of the operation that says you must return a representation of the resource created.

Even if you don't buy that argument....

in the same format it is POSTED?

The Ur-example of a REST application is the world wide web. We download a form, fill it in, and submit. In most cases, the contents of the form travel to the server as an application/x-www-form-urlencoded collection of key value pairs. How often do you get one of those back from the server? Never, or some close approximation to, because the responses come back in text/html (or some similar variant).

If your "pragmatic approach" can point to a precedent on the world-wide-web, you are likely to be on solid ground.

is it really that bad NOT to return a created resource ... in the same format it is POSTED?

HTTP actually gives you a lot of freedom in how you respond to messages.

For example, the section that specifies the 200 OK response code describes the kind of representations you might see in the response body.

POST a representation of the status of, or results obtained from, the action;

"representation of the status of the action could just be

Congratulations! we created a resource.

There's nothing in the semantics of the operation that says you must return a representation of the resource created.

Even if you don't buy that argument....

in the same format it is POSTED?

The Ur-example of a REST application is the world wide web. We download a form, fill it in, and submit. In most cases, the contents of the form travel to the server as an application/x-www-form-urlencoded collection of key value pairs. How often do you get one of those back from the server? Never, or some close approximation to, because the responses come back in text/html (or some similar variant).

If your "pragmatic approach" can point to a precedent on the world-wide-web, you are likely to be on solid ground.

Source Link
VoiceOfUnreason
  • 34.7k
  • 2
  • 45
  • 84

is it really that bad NOT to return a created resource ... in the same format it is POSTED?

HTTP actually gives you a lot of freedom in how you respond to messages.

For example, the section that specifies the 200 OK response code describes the kind of representations you might see in the response body.

POST a representation of the status of, or results obtained from, the action;

"representation of the status of the action could just be

Congratulations! we created a resource.

There's nothing in the semantics of the operation that says you must return a representation of the resource created.

Even if you don't buy that argument....

in the same format it is POSTED?

The Ur-example of a REST application is the world wide web. We download a form, fill it in, and submit. In most cases, the contents of the form travel to the server as an application/x-www-form-urlencoded collection of key value pairs. How often do you get one of those back from the server? Never, or some close approximation to, because the responses come back in text/html (or some similar variant).

If your "pragmatic approach" can point to a precedent on the world-wide-web, you are likely to be on solid ground.