LFWebAPIKit is the mainly the HTTP request class that serves as the backbone of ObjectiveFlickr and is also the HTTP request component that we use internally in all our products and client projects. It is now an independent project.
I came up with the idea to use git format-patch to extract the component from ObjectiveFlickr, and applied the extracted patches (in fact the change history) to the new tree.
After much thinking, I decided against requiring git submodule in ObjectiveFlickr1, so OF will always come up with its own copy of LFWebAPIKit. I'll sync between the two should change occurs in one place or the other.
For now there is no documentation for LFWebAPI kit yet. But it should be straightforward. Simply init an LFHTTPRequest object and that's it—the headers I believe are quite self-explanatory. Do remember two things: (1) Have appropriate delegate methods to receive the request result (or error), (2) remember to set the contentType to LFHTTPRequestWWWFormURLEncodedContentType if you want to send POST data in the form of key1=value1&key2=value2.
A few points in why you might be interested in yet another HTTP request object2: First of all, it works on both iPhone and Mac platforms. Secondly, it strikes a balance between expressiveness and simplicity—making an NSURLConnection is not straightforward but -[NSData dataWithContentsOfURL:] is not enough in many cases, and LFHTTPRequest saves you the hassle from the former but gives you more control (such as header, content type, agent, progress tracking and callback) than does the latter. Finally, and this is important if you're writing a Mac app, LFHTTPRequest works in common run loop modes instead of solely in the default mode. If you want your request to continue when you have a modal dialog box or a popup menu, this is important3. Finally, it handles redirect and lets you decide the policy for running into 404 or other responses4.
One last note: LFSiteReachability, the class that "does the reachability test right", is also part of the now-indepdenent LFWebAPIKit. You get all the goodies from one single repository.
The reason I decided against it is because, frankly, I think git submodule, functionally powerful as it is, represents everything that is done awfully about git: Scant documentation (which really puts off experimentation), bad user experience (funny commands, Spartan response messages), extra steps of human intervention (and without which nothing would work—the nasty git submodule init and git submodule update that all your cloned repositories have to repeat when one of their submodules gets updated). ↩
I know people from non-desktop platforms might even appall at the idea that you have to choose an HTTP request component before writing your app. The things is: You have more control over how the requests can be done in a desktop up, hence the choices. And as in most cases where choices exist: the default often quickly becomes not good enough. ↩
Each LFHTTPRequest is scheduled in the thread's run loop in which it is set to run (not in which it is initialized—it's unrelated). It uses the CFNetwork stack. ↩
Try making an HTTP request with a non-existent Flickr static image URL and a request with a non-existent Google page URL, and you'll see why the ability to decide the policy is important. ↩