POST Content-type encoding
Most modern REST API’s will take a look at your request’s
Content-type header. If the
Content-type is declared as
application/json, then the server expects your post body to be JSON. If the
x-www-form-urlencoded, then the body should be form and url encoded. Twitter, however, will only accept x-www-form-urlencoded post bodies. Your
Content-type will be ignored, and you will get a very unhelpful HTTP 403 status code back with an empty body. Unfortunately, this means that you will have to form and url encode your POST and PUT requests, which leads us into the next quirk.
URL encoding form parameters
encodeURIComponent. However, there’s just one tiny problem. The standard library function encodes a whole suite of characters, with a few notable exceptions. Specifically, it leaves out
[!,',(,),*]. This is because most servers don’t care, they know what you mean when you send a * or ! character, but Twitter doesn’t. To deal with this issue, the MDN encodeURIComponent documentation provides a fixed encodeURIComponent.
Not doing this will result in an just as helpful of an error as JSON encoding the body, a 401 HTTP status code with an body that states “Error: Unauthorized”.
Make sure to account for these two quirks, and your experience with Twitter will be much better.
One more thing. While trying to fix this issue, we ran across a number of posts that claimed you have to alphabetically sort your params by their key. We experimented with this and found we could post them up in any order.