RESTful API v2

[sekjal]

Libki's API has grown organically over the years. For example, clients are listed at /api/public/datatables/clients, while prints and reservations are under /public/api/datatables/prints and /public/api/datatables/reservations. But Reservations creation/deletion are found at /api/public/reservations/... and let's not even start with Users.

I propose that a new, unified, RESTful API be developed in parallel with what we currently have. This would serve at /api/v2/..., and provide full CRUD support for the key objects in Libki. Once completed, the web UI would be converted over to use this new API for all its interactions. The Client, Print Manager and Print Station APIs (already versioned) would be kept longer for better backwards compatibility.

This would probably need to be done AFTER increasing permissions granularity.

[kylemhall]

Moving as much logic out of the old client API endpoints into "business logic" modules that could be used in both the old and new APIs would allow for a period of time where both versions are available, would allow for some length of transition period to give libraries time to upgrade clients instead of needing them all to be done in one fell swoop.

Another possibility would be to leave the old API as is and embargo new code affecting the client API for a release cycle or two to simplify the transition during client migration.