Web Services as a Back end [closed]

Question

I am contemplating a direction to take an application. The application is written in PHP which implements a MVC framework.

Some of my clients will require web services. I was thinking even building the basic PHP web interface on top of these web services (SOAP) and stopping the PHP application from accessing the database. I want to do this so that I will only have to maintain one set of code for the main PHP apllication to access data and also any other applications developed on top of this web service. Is this a common setup? Will it slow the application a lot?

I looked at using Django framework to setup the SOAP web service but then realized it will have trouble dealing with multiple identical databases based on which client is using it.

I looked at Symfony, but worry that PHP as a backend might be seen as insecure or unprofessional by some larger future clients and not enterprise usable.

I am thinking Axis2 right now. Java might be faster as the backend and it will be marketable to potential clients.

What other Web Service framework should I consider? Is this Web Services Backend / PHP/HTML front end a usable solution?

Answer 1

Yes, this is a very common setup in larger applications. However, every web service call will add an additional delay to your application. So you need to design your web service very well to reduce the number of round trips an to reduce the amount of data you have to fetch from the service.

I would suggest that you stick with the language your are most familiar with.

Regarding Django and multiple databases: Django has builtin support for multiple databases. You can use them on a per-query base or a per-model base (and even use different database for read/write operations of the same model).

Answer 2

This approach is pretty common and makes more sense if you are really building a platform where others will develop on it. By consuming your webservices exclusively in your own app(eating your own dogfood), you will be validating the strength of your platform. Things to make sure you cover:

On the web services platform:

• Cache as much has you can for read operations, both from storing database servers in memory or memcache servers and also using a CDN for web services that are more static (i.e. web services that return lookup data (The key is to reduce the amount of disk I/O your overall system will make). As programmers we often forget that we can save alot of processing resources by offloading to external CDN servers
  • Dont forget to cache responses using gzip to reduce download times
  • Consider returning richer objects to minimize roundtrips so that client applications dont make extra calls. i.e. instead of returning a list of invoice objects you could also nest the invoice-item objects within a getinvoices type of web service. With compressed responses, it would be that much heavier and you save on roundtrips. Even better would be to allow calling applications to pass in a flag to determine how "rich" the return objects are
  • Issue api keys to different clients and validate so you can manage traffic, rate-limit and prevent abuse
  • I know you mentioned SOAP, but do you might need a plan for pure restful json/xml type apis if the consumer ecosystem will be pretty open to ease adoption