A Little questioning of your methods.

you do know what you have done is wrapped up a remote file execution (that's normal web serving) into a JSON-RPC execution system. (not really implement a JSON-RPC v2 Server)

It would be much better on my server for me to take you test.php file and add `test($_GET);` to the end of it and then make the call to /test.php?0=some&1=value; or named parameters as /test.php?name1=some&name2=value;

You are also aware that the JSON-RPC V2 spec supports `.` inside method names, the parameter is called 'method' that should have been hint that the calls should be methods of classes/objects you would be far better off using `spl_autoload_register` and supporting ClassName.MethodName and using the autoloader to support that, your massive wasting of memory on your server if every method call has its own file.

Also, your batch process would be better if it used some measure of async and not 1 after another that's what the id parameter is for.

In the end PHP via a WebServer is not really suited to be used as an RPC server as it's not persistent, and not easily async compatible.

Also as another side note, how do you handle notification requests? as your system is always providing a response going against the Spec's.

I really like what you have tried to do here I just wanted to provide some tips on how you could better handle the method calls and explain the limits of PHP preventing full spec implementation.

If you really want to implement a PHP JSON-RPC V2 Server you are better off building a Command line application that creates a persistent web server that handles with these requests and using an autoloader you could have a far more suitable system.

Thanks for looking so closely into the code, and your helpful comments.

Re using HTTP as the transport protocol: Yes it is a somewhat heavy protocol, but it has the benefit of easily passing through most networks. Furthermore, if I'd not been using HTTP I would probably also have chosen something other than PHP to implement it.

Re using PHP: Yes, if I was starting from scratch I'd probably use node.js rather than PHP for this. (And then I wouldn't be publishing it in PHPClasses.)

Re asynch processing of separate methods in the same request packet: Although I can see how you would spawn multiple threads, I have no idea how you would gather the results into a single (array object) response to reply to the client as the spec defines. How do you do this?

Also, wouldn't doing this from PHP would be hugely inefficient?
Isn't node.js fast specifically because it does not spawn multiple threads with their inherent overhead, but uses the JS engine's queuing methods instead?

Re PHP synchronous call (CURL) client: I agree, I would avoid using it. Having a script waiting for an inter-process/across network response is not ideal (though PDO is doing it all the time of course). It was just really to try it out. I am not sure in pure PHP if there is a better way to implement this - if so I would love to know it.

Re notifications having no response: It is probably dancing on a pinhead, but the RPC server does not respond (even though the HTTP wrapper (of course) does). In my case, I've not needed notifications, so I've not actually dealt with the situation in practice.

Re memory use: I am not clear why loading a file manually or loading it using autoloader would differ much. In either case, you eventually have to load the code. Furthermore, autoloader has the overhead of searching every other possibility before calling the loader function. The only difference I can see is that autoloader is doing some of its work in 'C' rather than PHP, which would be a time rather than a memory overhead. Perhaps you can clarify this point for me. Always looking to learn!

As an aside, the methods I have actually written for this server are 'getdata' which runs an SQL query (read from a library of queries - not in the call itself!) and 'getmeta' which retrieves metadata for the columns of an SQL request (again retrieved from a library). I also wrote a 'getrelations' method, but I've yet to find it useful in reality.