[katello-devel] API documentation proposal
Ivan Nečas
inecas at redhat.com
Wed May 2 14:22:07 UTC 2012
Hi,
I would like to share with you the first artifacts of the effort to
build a sustainable API documentation (not only) for Katello. Last year
I've proposed a master thesis topic on the REST api documentation tool
for Rails framework at local university and after a while a student
Pavel Pokorny responded positively to this topic and so the story began.
The original idea came from my hobby experimental project active_doc
(https://github.com/iNecas/active_doc) which aimed to provide DSL to
describe the code instead of just using plain comments. The advantage of
this approach is that you have the documentation available on the
run-time so that you can do additional things like validating that the
coming requests are consistent with the documentation or serve the
documentation to the client directly etc.
The project coming from this cooperation is called rails-restapi
(https://github.com/Pajk/rails-restapi - we haven't found better name
for that so far:). You can see a sample output at
http://restapi-likes.rhcloud.com/
http://restapi-likes.rhcloud.com/apidoc#twitter_example (you can get
there from the bottom of previous page)
http://restapi-likes.rhcloud.com/apidoc#twitter_example/lookup
We can divide the whole project into 4 parts:
*1. DSL for describing the requests*, e.g.:
api :POST, "/organizations/:organization_id/environments", "Create an
environment in organization"
param :organization_id, :identifier, :required => true
param :environment, Hash do
param :name, :identifier, :required => true, :desc => "Name of the
new environment, it has to be unique in the organization"
param :prior, :number, :required => true, :desc => "Id of the prior
environment. it has to be either Library or an environment at the end of
a chain"
param :description, String
end
error :code => 400, :desc => "In case the name is already taken or
the prior is neither Library nor environment at the end of the chain"
desc <<-DESC
Long description for the action. You can use RDoc formatting for this
description.
DESC
def create
# ...
end
We can describe what path and http method to use do to some action.
With keyword param we specify the arguments we expect. We can also
specify what value we expect (e.g. with type like Fixnum, String; with
enumerating acceptable values (["redhat", "custom"]), regular expression
(/^\w+@\w+\.\w{2,3}$) or with custom validator (:identifier, :number)).
You can also specify what error codes might the action return. With desc
you can write longer documentation using RDoc formatting.
This DSL can be used before each method of an action. You can similarly
give some basic documentation for the resource. (You can take a look at
fully described controller at
https://github.com/iNecas/katello/blob/restapi/src/app/controllers/api/environments_controller.rb)
*2. Validator for making sure the documentation is up-to date:*
When you say:
param :provider_type, ["redhat", "custom"]
it would be nice to make sure that these are the only values we
support. Therefore restapi provides a validation mode (configurable in
config/initializers/restapi.rb). When running in this mode, it will fail
when you try to call it with a value not valid with the description.
It's ideal combination with running API or CLI tests with this mode so
that you can make sure that the requests are really consistent with the
description.
*3. Engine providing the documentation through API
*
The plugin is using Rails Engine architecture to inject it's own routes
to the application where the documentation can be requested for further
processing (in JSON format).
*4. HTML client to the documentation server*
There is a sample HTML client provided with the restapi gem, that is
based on backbone.js. It uses the DOC API described in point 3.
If you run my branch of katello
(https://github.com/iNecas/katello/tree/restapi - remember to run bundle
install before and run the app itself in devel mode unless you are
willing to customize your apache configuration for static assets)
*Automatically generated doc based on CLI tests = API documentation line*
I've put together a tool for kick-starting the first documentation based
on requests to the API. The idea is to run all cli tests, watch the
requests and generate the documentation based on the requests, responses
and config/routes.rb. You can see the results in my branch restapi
(https://github.com/iNecas/katello/tree/restapi). It's not 100% exact
but is very useful for starting.
Before you start run bundle install (I've put a gem restapi.0.0.3.kt
with some tweaks not yet in the upstream version to a custom gem repo
http://inecas.fedorapeople.org/rubygems/, it's mentioned in the Gemfile).
You can run it in development environment and get the instant feedback
for you changes (in exchange for longer reload time), in production it's
much faster because the description not being reloaded.
When you go to:
https://localhost/katello/apidoc
you can see what all possible requests you can make to the API (some
paths might surprise you but that's what our routes.rb says = we need to
do some cleenup there).
I've updated documentation for environments a bit so that you can see
what it might look like:
https://localhost/katello/apidoc#environments
and what a action description might look like:
https://localhost/katello/apidoc#environments/create
There is still some work to do but I would like to hear your feedback,
suggestions, options on this approach. I hope it's the first step to get
more consistent and usable API for our project.
--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20120502/d45595da/attachment.htm>
More information about the katello-devel
mailing list