From SOAP to REST

Let me start by saying that the examples below are provided in order to illustrate a point before making inquires. Do not assume anything you see below constitutes good design or implementation.

We currently have a SOAP based API to allow customers to perform a few basic things with our system instead of manually doing them via our user portal. I’ve extended a lot of the Zend_Soap_* classes in order to customize a good amount of the functionality. In the end, it works pretty much like this:

A proxy class contains all of the methods. The Zend_Soap_AutoDiscover and Zend_Soap_Wsdl classes parse the docblocks in order to build the WSDL. The Zend_Soap_Server is told which class to use as the proxy, as well as an array of class mappings, to allow proper translation between the types defined in the WSDL and the PHP classes.

Here is a simplified implementation. I’ve left out all the enhancements I’ve made to the core Zend_Soap functionality, as I don’t think it’s needed

The WSDL would define three complex types, Request, Response, Record. It would also define two methods, CreateRecord and GetRecord. The SOAP libraries take care of all of the magic to make sure the WSDL is properly defined, that a client that sends a CreateRecord call gets routed to My_Soap_Proxy::CreateRecord, and that the method gets an instance of My_Soap_Type_Request. The WSDL is available at http://my.url.com/webservices/index.php?wsdl, and the endpoint itself is just http://my.url.com/webservices/index.php. That script is also pretty simple:

So, here is where my question about REST comes into play.

Is there any reason that, with possibly a few modifications, the proxy and type classes above can’t be used by a RESTful web service? You would have a single endpoint script, similar to the SOAP endpoint, that handles the requests, http://my.url.com/rest/endpoint.php, and single rewrite rule, /rest/(.*) -> /rest/endpoint.php, is all that is needed to send all the requests to that script.

The script itself would invoke the REST “server” class which would then be in charge of properly translating the provided data into an instance of the proper type class, passing that to the proper method in the proxy class, and then translating the response back into the proper format before sending it to the client.

I only have a very basic understanding of RESTful web services, so while that above seems obvious to me, it is very possible I am missing something. One reason I question such a solution, is that I constantly hear people talking about why RESTful web services are great, and SOAP web services are evil. While I agree that RESTful web services are much easier to understand and interface with, when a customer wants to know why their system’s SOAP based API can’t interface with your system, the fact you think SOAP is evil is not going to be a good answer.

Dependency Injection vs Encapsulation?

Let me start by saying that I LOVE the concept of dependency injection (DI) and feel that it should be utilized as much as possible. However, it seems to be somewhat contradictory to a concept that was drilled into me starting with my first programming classes: encapsulation.

Let me illustrate the conflict with an example. Proper DI techniques say that you should create your classes along these lines:

Where this seems to go against the concepts of encapsulation, is the fact that instances of Bar and Baz now have to exist outside of the Foo class. If interaction with those classes is not needed outside of the Foo class, wouldn’t it be better to hide it’s existence all together?

The example above might seem a bit trivial, but what if the creation of a Bar instance was very complex, but still requires nothing outside of the Foo class in order to create it?

Am I missing something? Even if they are conflicting paradigms, I think DI is the better option, but are they really conflicting?