PHP中的内部API，包含的替代方案？ [关闭]

Question

I've got 1 server with more than ten different standalone applications, all written in PHP. These applications communicate with each other through an API. There is one application on top to let them communicate with clients from outside the server, globally it looks like this:

The app who has to handle the hit responds in JSON to App 1, App 1 generates an appropriate answer to the hit, such as a webpage, image or just plain JSON, based on the information in the JSON.

If an application needs to communicate with another application, he will send a HTTP-request with cURL. Basically he becomes a client on his own server. I know this method consumes more resources than using a direct function, like Include or Require. But when I use these functions, I lose a lot of the standalone-principles.

The reason I like to stick with my standalone-principles is that I like to work with external junior programmers. I don’t want them to be obliged to use things like OOP, Classes etc. I want to say to them: “This is the input, I expect the output to be this, create a PHP-application to achieve it”.

My questions are:

• Does the HTTP-method use many more resources compared to direct functions like Include or Require?
• Are there better ways, besides Include or Require, to build a internal API with PHP?!

Answer 1

The answers to your questions:

1. It depends on a lot of things, including, but not limited to:

   • The location of your server
   • The number of nodes, and the quality of the nodes, between your servers
   • The latency of your servers
   • The format you use to convey the information

   To give you an idea of how this all pans out, consider the simple case where all your apps are virtual hosts on the same box. You are using curl to hit myserver.com/app1/ from app2. What you may not be aware of is that this:

   • Is forcing a DNS lookup to myserver.com
   • Will travel all the way out to the public interface of your router before looping back in

   Instead of the earlier scenario, consider this one: you are using curl to hit myserver2.com from myserver.com. The two are on a VPN together, but both also have a public interface where myserver.com and myserver2.com are bound to (respectively). The result? You're going over WAN when you could have tunneled through VPN.

In all cases, you will incur anywhere between ~10ms and ~50ms of latency per call, if the calls go to WAN.

"Direct functions" like include solve a completely different problem, but yes, they cut down on the entire HTTP request overhead. Direct instantiation should always be preferred, and your second best option should be caching the HTTP calls using something like redis.

Question two has a simple answer: Yes, not building one. If by an "internal API", you are building nothing more than a load-balancer, consider just using a load balancer. If you are building content mediation, consider abstracting it away and letting your devs actually do what they're good at.