When I had to do a very similar thing, I quickly decided that “RESTful is for the birds.”   I decided that it was both cumbersome and unnecessary to put parameters into a URL-string:   just put them in a JSON or XML packet, which can contain whatever information you want (including things that give URL-strings grief, such as product-id like PQ345/Z which contains a slash).   Sure, you can work around things like that in a REST string, but ... why bother?   After all, the URL-string is only one of several parts of the HTTP-block that you are sending and receiving.   Why use GET when you can POST?

After scoping the field, I used RPC::Any as a recently-developed and very well-developed infrastructure on the Perl side.   The client simply POSTs an XML or JSON packet to the server, and gets a similar packet in return.   The analogy is just like any sort of subroutine-call in which you send a structure (hash...) as your parameter-list and you get one back as your result.

Very simply, I think that “monkeying around with putting parameters in a URL string,” i.e. REST, is one of those ideas that might look great on paper, but that’s a PITA in practice.   It’s also a PITA that doesn’t buy you anything, given that you can do exactly the same thing with XML/JSON with none of the inherent restrictions.   Your Perl handlers get a hash as input, and they return a hash (or throw an exception, which is caught...) in return.   Q.E.D.

Three other things proved very helpful to me in my recent project:

1. In an initial handshake with the server, the client (PHP...) introduces itself and gets back a random token (like a cookie .. it could be a cookie) generated by the server which it must provide in all subsequent requests.   This gives the server complete and secure access to whatever context-information it may have need to store locally.
2. For each request of any kind that the client sends to the server, the client provides a separate random-string which the server must return verbatim with any reply, whether success or failure.   The client uses this to match-up requests with replies.
3. If requests might be coming from different sources within the client-side, arrange for the packets that are sent to contain perhaps more than one request and more than one reply.   (Since they’re just structured packets of data, you can easily return an array-of one or more such packets, given that each one has been given a distinct ID by the requester.)   It is desirable to minimize the number of times you have to turn-around the TCP/IP or pipe connection, and it is effortless to do so.

My experience with RPC::Any was, frankly, that I had found the “right” answer for my purposes.   I had it up and running in about two hours, most of that time spent reading.

Yes, as it happens, the back-end server uses Moose, but notice that it does not have to be Moose-based in order to work properly.   The architecture of this module is that it “demand-loads” the various handler modules, and it recognizes them without any “decorations” at all.   A modular and low-footprint server can be constructed very quickly, and I can see from the contributor’s description that this is what it’s doing in service at his place of business.