Client is presently hardcoded to use a PHP proxy

[jtlapp]

Hey Robert. How do you want to generalize the client to be independent of server implementation? Right now you POST a deletion request to proxy.php. It is possible for me to code the node.js proxy to receive requests at proxy.php, but that's unclean, and it may not be the case that the next proxy implementation will be able to handle that. node.js can handle it because node.js solutions are entire (simple) web servers and so have full control over the handling of everything.

Probably the most proper way to implement an API is to make it RESTful. Each resource has its own URL, and GET, POST, PUT, and DELETE are used to modify that resource. In this case, we'd have a single URL representing a shopping cart item, and we either PUT (to modify) or DELETE (to remove) the item. However, I'm okay with relaxing RESTfulness (ha!) and putting each request on its own URI. For example, we could have /cart/modify and /cart/delete. But if that's too hard to do in PHP, I guess we go with one service and make the operation a parameter. All of this is easy in node.js.

But we're left with the question of how does a client invoke a PHP script without using the PHP suffix. I know Apache is normally configured to run PHP only for files with the suffix. If this is the case, maybe the service URL must be configured on the client.

If I don't hear from you I'll probably proceed with something that seems PHP-favorable, even if the node.js community would frown on the solution -- maybe a single service URL that takes the operation as a parameter, with the URL being client-configured.

[jtlapp]

My nodejs-support pull request assumes all operations will be at the same proxy URL and has that URL configurable in a new proxyPath configuration variable.

[jtlapp]

Resolved in pull jtlapp/nodejs-support as described above.