18

I'm playing with the Twitter API and noticed something funny- For updates, they require POST methods but expect the arguments in the query string. (See for example, the status/update call in their developer console here.)

Obviously this is technically possible, but why would anyone do it like that? Don't POST arguments belong in the body?

Improve this question

3 Answers 3

Reset to default
13

Either option is just as valid. My favourite example for using parameters in the URL for a POST is an application that sets waypoints on a map. e.g.

 POST /map/route/45/waypoints?lat=35&long=74

In this case, the parameters make more sense in the URI as identifiers of a location, than just parameters being passed in the body to generic resource.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Just seems like it doesn't line up with the semantics. If I were on the processing end of the request, my POST VARS would be parsed from the body, GET VARS from the URL, always.
@Yarin I understand, but you are applying HTML concepts to HTTP where they don't exist in HTTP. The URI is a identifier and the body is a payload. From the perspective of HTTP GET and POST treat the URI identically.
This has nothing to do with HTML, which is part of a response. This is an HTTP request issue, where every definition of POST I've seen "The data is included in the body of the request" wiki, though searching the specs I haven't been able to find a hard rule on this.
@Yarin A few years ago I posted a related question to the HTTP working group mailing list and the response I got was that a POST with an empty body is perfectly valid. lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0272.html
@Yarin The problem is that Nathan confuses the issue by introducing the use of GET to do an unsafe operation and infers there is some relation between that and the existence of parameters in the URI. Uris are just identifiers and servers can choose to interpret parts of them as arguments to a server side process, that concept is valid irrespective of the method used. That's why the URI template spec doesn't mention HTTP methods. I do hear your concerns though, I just don't think there is any violation of the spec happening.
|
6

In REST architecture, GET and POST are just the verbs, which tells either to retrieve or create/update the resource. URI defines the identification of resource.

Example:

POST /student?name=Tom&age=12 >> It will create a new student with name Tom and age 12. POST /student/10?name=Tom&age=12 >> It will update student with id 20 with name Tom and age 12.

There is no rule that the data should be binded to body payload or URI. This is different from WEB 1.0 concepts where HTML form data is sent in POST.

Improve this answer

3 Comments

OK interesting- I wonder if in REST architecture POST arguments belong in the URL..
No, it is not like that.As i said, you can send them in URL if they are few, or send them in payload as json,xml or other media type if they are many. Its on the developer and how much he wants the api calls more easy and meaningful.
If you're doing an update, it should be done with PUT rather than POST
-2

If the arguments for WEB API are in the body or query depends on the Content-Type header you send in the POST.

If it forinstance is Content-Type: application/json; charset=UTF-8 then the arguments are expected in the body as json. If it is Content-Type: application/x-www-form-urlencoded; charset=UTF-8 then the arguments are expected in the query string

Improve this answer

1 Comment

I don't think this is accurate. If the Content-Type is application/x-ww-form-urlencoded, most APIs (in my experience) expect the parameters to be form url encoded in the request entity, not in the query string. And either way (application/json or application/x-www-urlencoded) some APIs accept a query string in addition to the request entity.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.