I am designing a REST API and facing a choice of formatting my POST methods to absorb parameters free-form via query string or content parameters:POST /my/api HTTP/1.0paramOne=XYZ&paramTwo=ABCor expect that a rigidly formatted data message (XML/JSON) be posted which encapsulates parameters:POST /my/api HTTP/1.0<requestClass>    <paramOne>XYZ</paramOne>    <paramTwo>ABC</paramTwo></requestClass>I have a preference for the second approach because it is cleaner (meaning a single code-level input argument vs multiple one, as well as basic format validation) and it also better accommodates data hierarchy (e.g. if paramTwo had sub entities, which, while not impossible, would be not so clean to implement in the query/form parameter approach):<requestClass>    <paramOne>XYZ</paramOne>    <paramTwo>        <subOne>1</subOne>        <subTwo>2</subTwo>    </paramTwo></requestClass>So, my question is, other than styling preferences, are there any other considerations in deciding whether a REST POST method should be taking parameters or a single encapsulating message? Are there any basic guidelines which approach to implement depending on different factors or environment? For example, does one approach present more of a security vulnerability than the other (I have an inkling it doesn't because both the content and query string can be sniffed equally easily and, in case of HTTPS it doesn't matter) etc.?If that matters, my services are written in Java and provided via Apache CXF running in Tomcat 7.
REST POST method design: query/form parameters vs. encapsulating content messages
design;rest;api
There is one concrete difference between the two.The length of the query string is severely limited (depending on what browser/server you are using) compared the the max size of a POST request8000 characters might seem like a lot, but if you are sending lists of things with long parameter names you can soon run out.Unless you have a defined number and max length of parameters you should use the request body