Services Kit features overview

The Kit.

First of all, let's talk about the good news. Among others things, I introduced most of the classes required to make HTTP requests over the network, just like the cURL library allows you to do. The Services Kit should be viewed just like an onion : the core of the kit is mainly responsible of managing the various protocols (HTTP, HTTPS, FTP, LDAP, ..).

In its simplest shape, the kit takes an URL, decide what protocol he should instantiate, make the request to retrieve a resource, ensure that the request is well completed and return an object containing all the resulting data. Advanced uses of the kit includes many protocol-defined options that can be sent to the protocol class to refine some of its behavior. For example, one can tell the HTTP protocol to follow every redirection it will encounter (which is the classic behavior of a browser), specify to store cookies or not, add an form which will be sent among the request, ...

I wanted to be sure that at least the most important protocol was implemented, and here it is : the HTTP protocol is almost fully handled in Services Kit. In fact, the only missing thing is a proxy manager, which is not introduced yet in the kit. The actually implemented features in the HTTP protocol are :

HTTP/1.1 requests as well as old HTTP/1.0 if the user wants it.

GET/HEAD/POST/PUT requests

Raw POST data upload (for basic forms)

Multipart MIME POST data upload (for complex forms with file upload )

) Chunked file uploads, allowing to upload a memory buffer just like it was a file and without knowing its size by advance.

HTTP authentication (basic and digest)

Optionally following redirection, with a max amount of redirections

Custom headers (in order to add and/or modify those who were generated by the kit)

Custom referer

Custom user-agent string

Full cookie management

Thanks to Stephan, my mentor, and his remarks, the cookie management classes has been refactored in order to have several performance improvements. They are now much more efficient (at least a 60% gain when working on big cookie database) than before when looking for the cookies of a specific domain thanks to a hash-map based storage.

Every protocol request lives in a separate thread from the main application, thus an app can do his own stuff until the request ends. The kit offers a few ways to send notifications to the application. The first one is to subclass a BUrlProtocolListener, register it as the protocol hook class, and it will receive various synchronous notifications coming from the protocol :