For some sites, text-based client apps may be a feasible alternative to Web browsers — but the same restrictions that sites use to deter spambots also make it hard to write text-based client programs that can post.
To find out how hard this would be, I just spent a little while investigating Twitter’s APIs, which I’ve never used before.
A program to fetch and display a user’s public Twitter posts is literally seven lines of Python; the hardest part of it is getting credentials from Twitter. Twitter requires that each client program have an “API secret” which is not supposed to be divulged to the user. Any given API secret is restricted in how many queries it can send, so if you share the same secret to everyone who uses your code base, it’ll stop working. (Unless you pay Twitter, I suppose.)
This pretty much means that you can’t hand everyone a Python script that lets them use Twitter from the command line; at minimum, each user would have to go on the Twitter API web site (logging in with a conventional browser) to get an API secret, then edit the script.
For posting or editing, Web APIs often require some sort of verification other than a username and password — such as a captcha answer, which depends on graphics. In the Twitter case, they won’t let an account post via the API without an associated mobile phone number.
For some sites, text-based client apps may be a feasible alternative to Web browsers — but the same restrictions that sites use to deter spambots also make it hard to write text-based client programs that can post.
To find out how hard this would be, I just spent a little while investigating Twitter’s APIs, which I’ve never used before.
A program to fetch and display a user’s public Twitter posts is literally seven lines of Python; the hardest part of it is getting credentials from Twitter. Twitter requires that each client program have an “API secret” which is not supposed to be divulged to the user. Any given API secret is restricted in how many queries it can send, so if you share the same secret to everyone who uses your code base, it’ll stop working. (Unless you pay Twitter, I suppose.)
This pretty much means that you can’t hand everyone a Python script that lets them use Twitter from the command line; at minimum, each user would have to go on the Twitter API web site (logging in with a conventional browser) to get an API secret, then edit the script.
For posting or editing, Web APIs often require some sort of verification other than a username and password — such as a captcha answer, which depends on graphics. In the Twitter case, they won’t let an account post via the API without an associated mobile phone number.
Whatever happens when the user logs into twitter with a conventional browser to get an api key is something you could do in your script.