On 07/29/11 - 10:25:39AM, Tomáš Hrčka wrote:
Here is the proposal for a API feature planned for this iteration.
The general idea is to create a RESTful API for conductor allowing
us to manage all conductor functionality through this API.
Currently we have some xml and json responses implemented in
For the beginning I suggest to use responder object to directly
render XML responses for collections,
lately when we want to stabilize the API we should use XML templates.
Here I propose features and tasks:
=== As a developer I want to have clean controllers.
* Move more code to before filters
* Move more code to models
=== As a developer I want to have full test suite for the API
* Implement all Rspec tests for the API
=== As a user I want to be able to consume xml API
* Add responder object to actions index and show for all controllers
=== As a user I want to be able to modify data through xml API
* Add responder object to actions update and destroy for all
=== As a user I want to have overview of the API
* Implement entry point for the API
* Implement/configure HTTP authentication
Question: do we want this to be HATEOAS (probably, but not spelled out here)?
While the above is a good start, I don't think this is particularly useful for
a user. In particular, I think we'll need to go further to at least implement
*some* actions that the user can take. Something like:
George (a user with a conductor account) can use a command-line call to launch
a deployment from conductor.
Jim (an admin with a conductor account) can use a command-line call to add a
new provider account.
I'm not saying that these are the scenarios we necessarily want to do first;
just that we need more examples about which scenarios we think are the most
compelling, so we can focus on implementing them first.