A PHP RESTful Implementation Library
I’m writing this to justify a project to myself (sometimes I find it useful to put pen-to-paper and gather my thoughts). The comments also let anyone else feedback (please do).
Proposal (the what)
1. Write a generic “HTTP library” for PHP that would include,
a) HTTP_Request - represents a single HTTP request
b) HTTP_Response - represents a single HTTP response
c) HTTP_Client - a client that would be able to send HTTP_Request and receive back an HTTP_Response
2. Use this library as the foundation for implementations of REST (and REST-like) services to immediately include,
a) Amazon S3
b) Amazon EC2
(this scratches a personal itch but these APIs also lack implementations, particularly EC2)
3. Evaluate whether this could be the beginning of a “RESTful Implementation Library” for PHP.
This is my big picture: a central collection of API implementations all based on the same foundation (#1). This would be a little like a niche version of PEAR but for implementations of RESTful web services.
Motivation (the why)
1. Frameworks keep reinventing this wheel.
I don’t really care that frameworks reinvent wheels, except that in this case it causes a definite problem when it comes to the implementation of 3rd-party APIs.
If you’re writing an implementation of the S3 API, what do you use to represent the request, response and client? Do you use an existing framework, extension, or write your own code?
If you use a framework package (like Zend_HTTP_Client) then you tie your API implementation to that framework. This sucks; I did this recently and started coding adaptors for different frameworks: that’s so dumb, having to abstract frameworks to make my library work!
The other alternative is to handle it yourself: you write your own request/response/client bits - perhaps even bundling them into the one class (not uncommon). Some of this type of implementation requirire cURL, which as an extension, may not be available in every environment (and certainly as a developer it isn’t the most friendly interface to use).
When you end up with disparate implementations I think you’re asking for trouble. You’ve got a lot different code solving the same problem; they probably behave differently and code-quality / testing is a big concern.
The bottom line is that there isn’t a core foundation for writing implementations of RESTful web services.
2. I like the general idea of a “one-stop-shop” for PHP web-service implementations.
Firstly it would rock for providers of APIs / implementors: they have a foundation to write their own implementation, taking care of the boring HTTP stuff, as well as potentially exposure to an existing audience. If you ignore the HTTP stuff, most APIs are pretty simple to implement.
Secondly, it would rock for developers using the APIs. They’re assured that the quality and behaviour of the HTTP part is consistent and they have a single resource to grab lots of different API implementations.
3. It solves a secondary problem
I personally feel PHP lacks HTTP request/response objects for the “current request”.
A lot of the current frameworks have some implementation of request/response and I think it’s generally a good idea. For some small projects I just use these objects from a framework: I use their request object, do some processing on it, create a response object, and then evaluate the response object (send headers + content).
It’d be nice to have an option for this in a “non-big-framework” way.
4. It scratches a personal itch.
I’m currently implementing Amazon EC2+S3 APIs and I need this sort of basic functionality. As I was coding I thought “why don’t I make this more generic so that I can reuse for other APIs?
Yes I know - existing solutions exist
Please don’t flame me!
I’m aware of PEAR::HTTP_Request, PECL::HTTP and the numerous implementations in existing frameworks. In fact I really like the ones in Zend and Solar.
I’m a lazy developer and I’ve got no itention of writing something from scratch or learning the gotchas first-hand. I intend to use the existing implementations as inspiration (subject to their licenses, which may even mean blatent copying) and also to keep in line with expected usage.
So, thoughts?
June 9th, 2008 at 1:49 am
[...] April has been coming along nicely. I’ve written most of the HTTP layer (Client, Request and [...]
September 17th, 2008 at 3:22 pm
Have you buiolt or found a PHP RESTful Implementation Library? This is why I like Rails…it’s RESTful!
April 3rd, 2009 at 1:51 am
[...] blog this now? As a part of APRIL I’ve been looking at the “server” component recently. This is the part of the [...]
April 4th, 2009 at 10:48 pm
[...] to it a lot. I’m planning on spend my programming-cycles finishing off the first release of APRIL and working on some other projects that always came 2nd best to “real work” (I need to [...]