CODEWITHSUNDEEP
phpapiintegrationwebhooks
mtindall89
mtindall89

Reputation: 419

PHP - Responding to incoming API call without returning

I'm trying to figure out the best way to send a response to an incoming API POST to our system, without returning.

We receive an XML post from another service, and consume it, and then our response to them is in XML also. What we are currently doing is digesting the incoming post, do some stuff on our end, then do a php return with the XML.

I would like to change this so that we can respond to their call with the XML, but then do some processing after the fact, without making some type of exec/background call.

What's the best way to send a response in PHP without returning? If we do an "echo" will that close the connection and allow us to process more afterwards without the other server "waiting?

Upvotes: 3

Views: 577

Answers (2)

Benni
Benni

Reputation: 1033

Calling PHP's echo will not close the connection, in fact you can call echo multiple times in your PHP script and the output will be added to the response. The connection will only close when

  1. The end of the script is reached
  2. exit() or the alias die() are called
  3. A fatal/parse error or an uncaught Exception occurs or your server runs out of memory
  4. The maximum script execution time which you can set in php.ini is exceeded

Usually, the calling client code will also have some kind of timeout, so if your 'digesting' code could take longer and you want to take care about this as well as point 4 in the list, you can store the request data for later processing, for example in a database or serialized in files. Having successfully stored the data, you then have basically 2 options to go:

Option 1: Spawn a background PHP process

To spawn a background PHP process that will survive the livecycle of the calling script, use exec and nohup. The basic usage could look like this:

exec('RESOURCE_ID=123 nohup /path/to/your/php/executable your_script.php > /dev/null');

Within the first segment of the command, RESOURCE_ID=123, you can pass a unique identifier of the previously stored request data, maybe a database entry id or the storage filename, to the background script. Use getenv('RESOURCE_ID') in your background script to retrieve the variable.

[EDIT] > /dev/null for output redirection is crucial for running the process in the background, otherwise the parent script will wait for the output of the background process. I also suggest to write the output as well as error output to an actual file like &> my_script.out, this will have the same effect. You could also get the process id of the background process by appending & echo $! to the command, exec() will then return it.

After starting the background script, you can send your 'OK' response and exit the parent script.

Option 2: Cronjob for processing, as suggested by Jim Panse

The more complex your system grows, you probably need more control over the execution of your 'digesting' code. Perhaps you want to balance server load peaks, or restart failed tasks, or throttle malicious usage of your API. If you need this kind of control, you are better off with this option.

Upvotes: 3

Jim Panse
Jim Panse

Reputation: 2270

Since i guess you want your system-to-system communication synchronously there are multiple things you can consider.

Even though time consuming requests you usually still want a fast response. To satisfy this you can't process the request immediately.

So, just save the request and process it later (give the client a 202 response back). Systems like queues are very popular to save time consuming jobs for running them later. Another time controlled script (cronjob) could then do polling and process the stacked messages/data.

If you want to provide the results to the client too, return them a unique resource id on the initial rest call and implement another resource with exactly this parameter as the input. If your system finished processing, the result will appear there.

Spawning a process from within another php script isn't very handy since it's very difficult to debug and error-prone.

I personally would't go for this solution.

Upvotes: 1

Related Questions