make a full API: rewrite the views.add method

[guyzmo]

I'm working on my fork in the api branch to add full blown API to nnmon.

I have added django-pastypie to the requirements, and implemented a first version to replace the /ajax/ route with the /api/ route, and it works pretty well.

The problem I'm now encountering is the following:

1. API inconsistency
   • for listing the violations, the API gets the list of models.Violation and exposes it,
   • to add a violation, the form on frontpage – and thus views.add – uses forms.Violation, which is a join between models.Violation, models.Comment and maybe others.
   • to solve this, there are two solutions:
   • the easy one: which is to match the API to forms.Violation,
   • the clean one: which is to refactor views.add() so it updates separately models.Violation, models.Comment and models.Attachment, and same thing on the API side, listing of the three models is also separated.
2. Error management
   • in the following method (which is the one managing the POST requests, so the Violation object creation):

        class APIResource(ModelResource):
            def obj_create(self, bundle, request, **kwargs):
                # XXX
                return bundle

I still did not undestand how to manage returned error codes in tastypie. I RTFM with no success until now.

1. Authentication: Turing test + Account creation

Finally, last problem about the API updates, is that you can't do a Turing test when using it, as it is intended to be M2M. So I think we can force the account use, by separating the Turing test using a standalone API so the user can get an API key in exchange of the test, his e-mail and a nickname.

[guyzmo]

I'm going to push my current changes in my repository in the api branch tomorrow.

[ogirardot]

for the first point, the website doesn't really have to implement the API, it can simply be a public API, right ? for the second point i'll think about it with you, but the "tastypie" way, would be to return a bad request http code with a json description of the error (i think).

[stef]

re: 1. the db format is a historically grown thing, due to the usage of SQL. sorry for that. i'd prefer a unified format for the API, not seperate endpoints for each db table.

[ogirardot]

you don't have to different endpoints for read, as tastypie allows following relations (foreign key etc...) and exposing it easily. As for writes, you can customize easily requests handling, but we just need to know what we want.