On Wednesday, 27 November 2013 at 00:49:57 UTC, H. S. Teoh wrote:
Sounds like the perfect job for a quick-n-dirty D program,
right?
Oh yeah, my http.d and dom.d can make short work of that. I had a
similar problem last year and ended up getting it to work very
easily (well, that one used my curl.d, but http.d does cookies
too now).
coding, I ran into a blocker: std.net.curl didn't let me specify
Content-Type of POST requests!!!
.....holy crap, you're not kidding. I thought addRequestHeader
can do it, but that duplicates the header. Unbelievable.
My curl.d is an ugly piece of garbage. Seriously, I hate it, just
look at this signature:
string curlAuth(string url, string data = null, string username =
null, string password = null, string contentType =
"application/x-www-form-urlencoded", string methodOverride =
null, string[] customHeaders = null, string cookieJar = null) {
but at least it gets the job done - I use it on my work projects
to access all kinds of things from arbitrary website downloads
(one of the work sites offers a link posting functionality
similar to Facebook, it downloads the site and reads description,
images, etc. to make a richer link preview) to a variety of APIs
like bing search, Facebook, twitter, linkedin, youtube,
Authorize.net, I've done a lot with it, and especially my helper
oauth.d file for many of them, all built on top of this hideous
do-it-all function.
If I was doing a whole new interface, I think I'd prefer to do an
object that keeps this state internally. So it'd be like:
auto client = new HttpClient("host", port);
client.userAgent = "whatever";
// authorization would ideally be a UFCS function or at least do
some template method check, so it can be extended by things like
oauth
client.authorization = BasicAuth("username", "password");
client.host = "host override if you want.com";
auto response = client.post("/login", ["username":"lol",
"password":"rofl"]);
// or
client.post("/login", "text/plain", "text");
// or
client.post("/login", "text/xml", someXmlInputRange);
or something like that. Url and method could be set via
properties too; get, post, head, put, delete, and so on could
perhaps be implemented in terms of opDispatch that sets the
properties then calls .execute();
Anyway, the important thing would be if you do future changes to
this object, it maintains a bit of state. Cookies and such. That
could work with async too, since the response returned would be
more like a handle, so you then do
response.wait();
or do callbacks or whatever.
But the point is it'd be nice and simple for most series of
requests.
