I have searched well before asking this question, and some of the questions look like what I need here, but none of the gave a clear answer to my question.

I am writing a web application (in PHP if that matters) that is separated into multiple sub-applications (e.g. Auth, Database, Session, ...etc)

Each of of these sub-applications is deployed to a separate server, and some are deployed on the same server, but not for too long, eventually they will be deployed to their own servers.

Now, my question is simple. What is the standard/correct way of communication between these parts?

I am not sure, but consuming the APIs of these applications over HTTP/HTTPS sounds a bad idea.

Maybe Messaging protocols? Sockets? I am not sure! As I said, I only want to know what is the standard way to handle such cases?

有帮助吗?

解决方案

The "standard" way would (currently) be HTTPS REST style calls.

It's not the most efficient or best, but it works and is well supported across technology stacks.

An alternative is message queues. Generally these are for async communication, but you can make RPC style calls using them too if required.

The main problem with other alternatives is they require client/server libraries in your language of choice.

If I write my c# WCF service for example, can your PHP website talk to it?

许可以下: CC-BY-SA归因
scroll top