I started hacking on this in the interest of getting a better idea of exactly what it's going to take. Here's my WIP: https://github.com/KevinCorcoran/puppet-server/commit/b9267b66c8b6e7a1a6e327ebb3aa92e78c6f1a94
And here are my other thoughts/notes:
- We have 4 total endpoints/defresources : /cert_status, /cert_statuses, and the 2 admin endpoints
- As seen in the commit above, I started using ring-json which provides middleware for auto-rendering maps, etc. to JSON strings ... I was surprised to learn that we are not already using this for our existing endpoints .... but I guess that none of the ones implemented w/o liberator return JSON, perhaps.
- Error-handling is going to be the majority of the work. liberator has a specific API for this based on it’s DSL/decision tree … in the early endpoints we implemented in the CA, we throw exceptions from “internal/implementation” namespaces up to the namespace where the ring handler lives, catch the exceptions there, and turn them into ring responses. This code could probably be DRYed-up and perhaps some middleware extracted from it. This would probably be worth doing before un-liberating the /cert_status(es) endpoints.
- The defresource implementation for /certificate_status is, by far, the most complicated - the two endpoints in the admin API are much simpler and also nearly identical, so that ring handler should be much easier to port than the CA's.