How should I integrate two PHP applications - via common code, REST, RPC?

Question

I work on two related web applications, developed in PHP, that started independently. Over time, we have started to more tightly integrate their functionality for business reasons. To accomplish this, we setup a directory for common code in a seperate SVN repository so that we can deploy different versions of this code when we deploy each application separately. A text file in either application repository indicates which revision of the common code should be deployed.

If has worked fairly well so far, but there are some issues and considerations that have arisen:

• All of the code that is used by either application in this common interface needs to be 'visible' to both applications. For example, if an item in application #1 is saved through application #2, then all of the supporting code, ORM classes, supporting classes, etc., need to be in the common area.

• If application #1 is making method calls to application #2's code, then it is bypassing all of application #2's startup code - authentication, framework, etc. This could lead to un-desirable results and unexpected dependencies.

At this point, we prefer to keep the applications separate.

What would be considered the best way for these two applications to communicate with each other? We could use an http communication that ensures a reliable interface and that each application is handling processes through it's own application processes. We worry about incurring overhead from http, but the trade-off of a more loosely coupled system would probably surpass that concern.

At this time, both applications are running on the same set of servers, and, as mentioned, using PHP almost exclusively.

EDIT: The communication will be private and authenticated within the apps, meaning no plans for public API.

Answer 1

In my opinion, use an HTTP-based API. I've had to deal with this previously with a set of applications and common-code ended up coming back to bite me. Decouple them now if you can. A good implementation of caching data, using pub/sub instead of constant polling, etc should keep the overhead to a minimum.

Answer 2

It depends if you will want to integrate your application with some other applications. If yes, then I would rather use SOAP architecture so that you will have better interface for next apps, maybe in some other programming language.

Answer 3

It's a tradeoff you're making; A shared code base is - all considered - simpler and more efficient. At least in the short run.

An xml-rpc or plain http-based api can work well, and is good for separating responsibilities, since you get explicit boundaries. For the sake of completeness, SOAP is also an option, but one I wouldn't pick unless forced to.