It seems to me that using PATH_INFO is going to make things more complicated for clients, as instead of at a low level taking an assoc/dict/hash/etc of query parameters, they have to also take a PATH_INFO value. And while that's not much of a complication (if nothing else, a magic key could be extracted from the assoc/dict/hash/etc), what is the benefit?
Topic on Talk:Requests for comment/API roadmap
I agree that it will have to make "action" a special parameter (or could be extracted from the dict), but there are several benefits:
- Ability to easier partition server farm to create a cluster dedicated to certain actions - like parsing (requested by parsoid team)
- webserver access log files will contain the action even for post requests
- No need to introduce api2.php just yet - we can determine new version by request style
- Future core version changes can be done in the style api.php/action/2?...
- Shorter URL
Partitioning, ok. Versioning could as well be done with action=foo/2. api.log already contains the action for post requests; I guess you're talking about the webserver access.log? Shorter URL and "api2.php", meh.
Anomie, the core value is the #1 - everything else are side benefits :) As for logs, unless this is a very very recent change, I don't see action in the post req in the logs.
Are you looking in the api.log (on fluorine), or in webserver access logs?
I'm looking at the api log files that are rsynced to stats1.
I don't know what's in that one.