OAuth Signature Generation & JSON Request Bodies ~ Best Practices


I read the “Creating Signatures” page at https://dev.twitter.com/oauth/overview/creating-signatures.

I see that in some cases, the content type for requests to the Ads API seems to be “application/x-www-form-urlencoded” and in other cases “application/json; charset=utf-8”.

If we could use “application/json” for all requests, it would simplify OAuth signature generation.

For GET and DELETE requests, we would still pass key/value querystring pairs into the signature generator.

For PUT and POST requests, the request body can be ignored during OAuth signature generation if it is treated as binary data (a payload), rather than a set of key/value pairs.

Does Twitter have a set of best practices for how to handle each of these types of requests?

I started thinking about this when I used the new batch create campaign endpoint, where the request body is a JSON array. A JSON array is not a set of key/value pairs.

It turns out that the request body can be treated as data transparent to the OAuth signature for this type of request.

Since we are using HTTPS for the Twitter API requests, I don’t think we necessarily need the extra layer of security provided by an OAuth Signature. Its acting like a checksum.

Another peculiarity we found is that if any body parameters are set with null as the value, in a form-encoded request body, the OAuth Signature generation doesn’t seem to work properly, and we get 401 Request Unauthorized. We worked around this by passing “NULL” for the property value, and that had the intended effect.

At any rate, any feedback on these things is appreciated.

Related Post:

So, I guess the simplest most consistent convention would be:

  • always use “application/json” as the content-type
  • by the RFC definition, querystrings are always considered when generating the OAuth signature
  • request body (if any for PUT & POST requests) is always ignored due to the content-type

I don’t think I can use that convention, as it seems like some API calls expect the form data content type, rather than JSON.