+1 on everything here.

My only  comments:

Point 1)

We have many different consumers (personas) of the API.  Some may simply want to build images, others may want to launch and so on.  The difficulty here is putting a weighting on each persona i.e. is one persona more important than the other?

Ideally we would get feedback from existing customers and build a priority list.

If we can't get hold of this information, an alternate approach could be we look at core functionality of Aeolus? i.e. Why are we better than just using deltacloud, or imagefactory? and focus our efforts on the bits of each persona that are associated with this.

Point iii)

Absolutely we do not want to blindly copy the database schema.  We should be very careful and consider each resource we aim to expose.  Some of the information / models are for internal use and don't make sense to an end user.

Point iv)

+1 - In fact the initial implementation was done in this way.  But as the UI around image management started being built many methods were reimplemented (rather than simply calling the API methods) for the same functionality.  Controillers we ended up with duplicated code and the thing was a mess.  In the end we ended up moving API + UI into single controlllers.

I actually think that the UI controllers should sit on top of the API controllers.  Even if the controllers are simply making native calls (rather than ReST).  It allows the components to be separated out. 

To me this makes sense on a couple levels. 

All IMHOs,

Thanks

Martyn




On 01/16/2013 02:09 PM, Martin Povolny wrote:
While I am at the writing mood today I would like to say a couple of
things to the API. All these are IMHOs so let's pretend there's a IMHO
in front of each point.

i) the API implementation should start with what the consumer needs or
wants

1) the client would want to start with launching things (deployment)
2) next the client would want to check if the thing he wanted to run
actually runs
3) next the client may want something else like list all the stuff he
has

ii) the API needs a client to check it's actually good

I already wrote in a different thread that freezing the API before
verifying that it's actually usable by having at least one client is not
a good idea. In our project probably the first client is the CLI.

iii) the API structure need not copy the internal structure of the
project (being it the models or the controllers)

Actually the API should hide the implementation details as much as
possible and it should be structured in a way that is logical from the
consumer point of view.

iv) from the above it's obvious that having the API in the same
controllers that serve the WUI might not always be the best way to do
not only in terms of spaghetti popularity.

These are just IMHOs, but thanks for reading up to this point!