thirst and thrust

I have covered a couple of REST topics previously, Who Needs REST? and Now for the REST of the Story. I started playing around with a client library used to consume rest services and discuss the experience below.

The approaches
My first approach was to create a version of the client using a strategy pattern. By using it I encapsulated the GET, POST, PUT, and DELETE request into their own objects. While using a context class to store the “state” of the request as well as interact with the underlying request object.

I also decided to create a version of the client library request functionality into a prototype pattern. The thinking there was that the strategy pattern was a little overkill given the fact that the request objects created in it were really only different in the method being set on the header. Also the strategy pattern lead to a lot of class creation which might affect performance. One of the advertised benefits of the prototype is to cut down on the amount of class instantiation through the “new” key word, which in some programming languages can be much more expensive than a shallow copy (clone) of an existing object. This also allowed me to put the bulk of the request implementation in an abstract class that would allow me to implement the duplicate code I had in the strategy pattern to be done once. As a matter of fact the only thing the concrete prototype classes that implemented each of the REST HTTP request types was to set which type of request was being used).

Another thing I did was create an HTTP request utility class that encapsulated the PEAR HTTP Request package implementation. This class was used by both approaches mentioned above.

So I set out to test these two approaches just to see what I could learn. I hooked up both implementations to a test page which had some benchmarking code which counted microseconds for execution of operations (I will blog about the benchmarking code at another time).

Why is benchmarking important as a test in this instance?
One thing I realized in playing around with REST web services is in order to do anything moderately complex in the business logic a lot of request need to happen in the background (especially GET requests). So it stands to reason that the footprint of the numerous requests should be as optimized as possible.

What was learned?
On a single request the strategy request approach was most efficient. This makes sense since the prototype implementation uses a factory pattern as an interface that instantiates an object for each concrete request prototype and is cloned from an associative array containing the objects. There is overhead associated with this versus the more straight forward strategy pattern. This overhead happens once and is not much of an issue if an instance factory class is used for a number of requests.

Over a large number of request (1000 in my test) the prototype implementation performed better but only marginally. The prototype implementation shaved about 0.8 of a second from the execution time versus the strategy implementation. Both took over 17 second to complete the requests (not great for a web page load time). What this tells me is that in php the magic function __clone() is not that optimized over a “new” operation. The main drive for using the prototype implementation was to cut down on class creation overhead which does not really pan out in php.

A better approach may be to use the REST request utility class (used for encapsulating the PEAR implementation) directly versus using either pattern approaches. To do this I would add some convenience functions to simplify the interaction between the business logic and the utility class.

The code
The code discussed above can be downloaded through a Google code project I set up for this blog. It can be downloaded as a zip file containing the source or accessed through SVN anonymous checkout.

Share on Facebook