Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Is it a common practice to create an HTTP POST end point (with the header “application/x-www-form-urlencoded”) that takes in a JSON string as the value of the key/value POST data instead of having a list of fields as the POST data? Regardless of being common or not, is it considered bad since it requires more work to stringify the fields into a JSON string?
Example:
user={“username”:”bob”, “age”:1} vs username=bob&age=1 in the POST form data.
This is actually very common – the SOAP messaging format does just this; replacing the standard POST body with a custom messaging format (in the case of SOAP it is XML).
The only thing to consider is that HTTP is pretty ubiquitous these days and although it is trivial to find a JSON library for any language, creating a HTTP body is utterly simple.
So it isn’t bad by any means, but if the client is serializing to JSON and then you are deserializing from JSON, would it just be easier to use standard HTTP message bodies?