Hello,
Pardon the ignorance, I am not a stranger to working with HTTP, novice when it comes to Twitter API, however.
Just looking for a bottom line boilerplace pattern, I have a request, what should go in the header, how to form the request, Url, parameters, that much is pretty well documented I think.
Then nuances around the scaffold of the request, transaction and/or session of sorts, things like rate limiting, keep alives, or other nuances to consider.
Preferably language agnostic, but fine if it is not. And if not, leaning toward dotnet and csharp, but again, can work with it, if not.
Then once I receive a response what I might expect… Again in terms of documented API, mostly pretty well documented, I think. Is there any trickery involved, are there sometimes multi-parts, I’ve seen that in places, along these lines.
Thanks…
I’m not really sure what you’re looking for - do you have some examples?
There are some common patterns that keep coming up in the API and as solutions in different libraries - but it depends on what you’re doing - things like retries, etc. There’s a lot of undocumented stuff - and the twitter specifics are sometimes hidden away in hacks in the code - things like avoiding rate limit errors by waiting an extra few seconds at reset time twarc/decorators2.py at main · DocNow/twarc · GitHub (Python example) Is that the kind of thing you’re talking about? I don’t think there’s a good general guide on that unfortunately.
Generally, I think, working from authorizing a request. Decomposing that. Difference between the mess that is the OAuth Authorization, and the actual Request Headers. oauth kvps are not the same thing as request headers, is that accurate? Does the whole hashed encoded OAuth thingy involve any of the other Header entries, or is that just a natural language illustration sans assembling the various joined hashed encoded constituent parts? Does it make sense? Understanding what contributes to the signature, the OAuth thingy, do I need to present quoted values to the signature or the raw keys and values, along these lines. I’m nearly ‘there’ I think.
Oh, all that is oAuth related, and generally it’s not advisable to bother implementing that your self and reinventing the wheel. That’s documented here: Creating a signature | Docs | Twitter Developer Platform
The headers do matter and are part of the auth, and have to be in the right order and properly formatted. The values in the docs examples should match up, but will not be usable for making live calls as you’ll have to replace the keys with your own.
Generally, it’s not worth your time to dig into the specifics of Twitter’s implementation of oAuth1.0a - it’s easier to just use a library that does it for you, given a set of keys: Twitter API v2 tools & libraries | Docs | Twitter Developer Platform
1 Like
Yes, I understand that, re: advisements and all. I have the necessary dotnet library support in that regard. What I am more interested in is, when to quote or not the string values. Seems like probably not, at least from cursory informed inspecfion of various “yet another tweeter” client implementations in OS. Generally thinking I can probably dial back 2-3 properties+methods in my headers effort, but just getting a feel when to or not to quotes and so forth.
So given the example final Authorization HTTP header string.
OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog", oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg", oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1318622958", oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb", oauth_version="1.0"
oauth_signature is bascially taking all the OAuth kvps we see there, sans the quoting, rolled up with appropriate ampersand (&) and equal (=) pairing, plus any other url query parameters, and the url method and address bits. Basically like a fancy CRC calculation on the whole thing. All that and it lands as what we see here, i.e. tnnArxj06cWHq44gCs1OSKk%2FjLY%3D.
At the time of calculation we would not know the signature, obviously, so that gets incorporated after the fact, all ordered by the keys. But do we include oauth_signature_method in the signature calculation? Or that also is after the fact?
Is the signature calculation taking into account any of the HTTP request headers? Or just what we see here and such?
As far as i can tell i think quoting / not quoting actually depends on the library / language - in the end, the signature base string etc does not quote string values, they’re % encoded not quoted - but i’d let the library handle those details.
And then what happens if you happen to also have a Bearer token? that is in lieu of the Access+Consumer tokens?
Yep, exactly - it’s either or - Bearer token auth is oauth2.0 standard, consumer keys and access tokens are oauth1.0a standard
Gotcha. Otherwise all the rest, the gathering, ordering, etc, is consistent? i.e. where do I put that in terms of what, oauth_bearer_token?
Or in dotnet csharp, I just set the request header something like this. I need to hash or encode at all?
// HttpWebRequest request...
request.Headers.Add(HttpRequestHeader.Authorization, $"Bearer {bearerToken}");
And that’s it? No messing around with signatures or what not?
1 Like
Reviewing the samples, specifically samples stream also, gotta be honest, not seeing a lot of value add in posting those on github. I know how to do web, requests, getting responses, even dealing with the response data, along these lines, how about showing parameters and so forth. Even in a java, probably the closest analog to a dotnet or csharp use case.
I think I have a minor success. Did a transform of my app settings config with bearer tokens and such, and I think I am staring at a perpetually running sample stream. Does it time out ever? Or do I need to hang up, so to speak, client side? What am I receiving exactly. An open stream, obviously, but is it a continual run-on Json text? Individual Json object texts, separated by whitespace? Need to decompose that yet, have not quite got that far; I have a message handler installed in my client that I can break out the request and response for operational or diagnostic purposes, so the rest is to start breaking out the response, stream and such. Cheers 
1 Like
Yep, that’s it exactly! Sometimes you get just newlines and normally it’s 1 tweet object separated by a newline in the stream - like downloading an infinitely large file line by line
Cheers , mate, Happy to make your forum 
acquaintance. Thanks again.
1 Like
