IMHOs on the API

Martyn Taylor mtaylor at redhat.com
Thu Jan 17 10:32:05 UTC 2013


+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.

  * The UI guys can focus on what they do best "Building UIs",
  * It allows customers to deploy only the API (feedback from existing
    users has hinted that they do not use the UI at all and only use the
    API).
  * We can componentise the UI.  Only deploy the bits of the UI that
    people want + the API (for example self-service portal)
  * The UI and the API fucntionality is very different.  The UI is meant
    for end user consumption and as such has totally different
    workflows, combines information from many unassociated resources and
    holds state.  All very different from a ReST API.

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!
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20130117/2f044b39/attachment-0001.html>


More information about the aeolus-devel mailing list