[katello-devel] API V2 format changes

Martin Bacovsky mbacovsk at redhat.com
Thu Mar 7 16:46:29 UTC 2013


We (Tomas and Martin) are working on API redesign and cleanup. The 
motivation for this is that the practices are not consistent in current 
API which makes UX not pleasant and is causing difficulties while 
creating CLI. In the future it could be possible to autogenerate python 
bindings for Katello  and/or parts of the CLI.

Current state
     * nesting of elements is not consistent
     * when use of as_json the representation of entities is distributed 
over the code
     * some results render as text instead of JSON

Our goals:
     * make the transition as simple as possible
     * use RABL for JSON output definition
     * make responses consistent
     * unify error handling
     * make it easy to change the output behaviour from one place

There are some decision that needs to be done. We are looking for 
opinions on following things:

     Support messages in 2XX responses? e.g. 'message: "Environment was 
successfully deleted"'

     Pagination handeling
     * support in every GET that returns collection or just where it 
make sense?
     * suggested format 
/api/organizations/<org>/environments/?page=2&items_per_page=20
     * Should result contain item count, offset, items per page?

     POST
     * return 201 or 200?
     * return URI or entitiy in body?

     PUT
     * return entity or empty body?

JSON conventions for V2 as we would prefer them to be, but is subject to 
changes according to comments on questions s above

     GET
     * returns either entity or list of entities
     * pagination supported where it makes sense, no extra information 
in paginated response, add methods entities_count or similar
     * all entities have root

     POST
     * 201
     * return entity in body, URI in Location

     PUT
     * 200
     * entity in body

     DELETE
     * 200
     * empty body

     No messages in 2XX responses. (status of the action is told by the 
code, passing it to the user should be responsibility of client app)


Work shown in the pull request 
(https://github.com/Katello/katello/pull/1714) should demonstrate the 
desired state of things after our mission is completed. We choosed 
environments as a suitable sample controller:

     V1 refactoring to minimize changes in controllers in V2 and to 
avoid support of two sets of controllers as much as possible
     * isolated output handling to set of methods, taht could be changed 
in the next version without need to touch the controllers
     * keep the V1 behavior unchanged is priority
     * change inheritance of the controllers to allow inherit V2 
controllers from the V1 ones while adding V2 specific behaviour from module

     V2
     * added RABL templates

TODO
     * handeling of errors in V2
     * pagination support

Comments are welcome,
Martin




More information about the katello-devel mailing list