views:

59

answers:

3

I've been asked to help a friend's company to bring up a web application. I have very limited time and I reluctantly accepted the request, at one condition. As most of the logic goes on in the back-end, I suggested that I would finish the complete back-end only, allowing a front-end developer to simply interface with my backend.

I plan to do the back-end in Java EE or Python (with Pylons). It does not really matter at this point. I plan to have my back-end completely ready and unit-tested, so that my input will hardly be needed after my work is done.

I know they have a PHP programmer, but as far as I could tell he is a real rookie. I want him to basically interface with my backend's services in the easiest possible way, with no way of him "stuffing" it up. It's basically a CRUD-only application.

I could implement the backend as accessible through a webservice such as XML-RPC or SOAP. Even a RESTful API could be possible.

However, my main objective is to make something that complete "noob" PHP programmer can easily interface with without getting confused. Preferably I do not even want to talk to him because I generally have an extremely busy schedule, and doing "support calls" is not something I am willing to do. Which approach should I choose? I would welcome any suggestions and inputs!

+3  A: 

I would personally choose a REST API, probably with a JSON response. SOAP and XML can be a bit heavy-handed for simple services, and even the most novice web developer understands the concept of accessing a basic URL, even if they don't grok the overall concept of REST. There are myriads of ways to work with URLs in PHP, so I'm sure they'd be able to come up with something, even if it was a hack job instead of a nice client package.

I would also likely choose JSON encoding and decoding, as it's generally fairly straightforward, while XML parsing can be a bit more daunting.

I would also write up at least some basic documentation on the service, no matter what formats you choose. Otherwise there's no way you will escape support calls. Your target consumer must have a reference of the remote actions available to him, or a method to discover those actions. It would probably take you 10 minutes to whip up some example code when it's ready, and those 10 minutes could save you a lot of emailing.

zombat
+1 on REST, +2 on JSON, +3 on document it.... now i owe you 5 points...
Javier
Good idea. I am convinced to go with a RESTful API on this one. As for the basic documentation, we'll have a requirements document with mockups of screenshots and all, so he can't go wrong with this.As for JSON vs params over GET/POST query strings, I think the latter, I'll have to think about it..Thanks!
T.K.
+1  A: 

Definitly go with a rest-like implementation, and return query string formatted output.

Just remember that php will turn array like variables into an array on the php side.

Take a query string for your parameters

Input: p1=v1&p2=v2....

Output: output1=var1&output[0]=var2;output[2]=var3

Accessing this in php is then a simple as

<?
   $request['myparam1'] = param; 
   ...
   $webService ="http://path.to.service?".http_build_query($request);

   parse_str(file_get_contents($webService),$response);

   // response is now an array with you response parameters in it
   // $response['responseParam1'], reponse['responseParam1'] etc
 ?>
Byron Whitlock
it's easier and more predictable on both sides to just use JSON
Javier
Thanks Byron. I'm still stuck between deciding whether to go for parse_str and JSON. I'll have to give it some good thought.
T.K.
+1  A: 

Been there, done that.

Backend in Django, frontend in PHP by a 'we do pages' contractor. i whipped up a REST-like API using JSON, provided them with a couple of 5-line PHP functions to access my service as a key-value store.

After a couple of false starts (where they tried a contrived and redirections scheme instead of using the functions i sent them), they got it and everything went smoothly after that.

Javier
I think I've decided to go the JSON way now. :)
T.K.