IMHOs on the API

Petr Blaho pblaho at redhat.com
Thu Jan 17 09:42:16 UTC 2013


On Wed, Jan 16, 2013 at 03:09:13PM +0100, 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!
>
> --
> Martin Povolny <mpovolny at redhat.com>
> tel. +420777714458

Points i) to iii):

I perceive them as Outside-In development as proposed by cucumber
community but extended outside single application to include clients of
API too.

So I hope that our future work on CLI will lead us to correct, update,
enhance and build new API endpoints if this will be needed.


Point iii):

I agree that it is not necessary to just expose every controller as a
resource (as viewed from API pow).
In fact I do not like model-controller-resource relationship in a 1-1-1
form. I looks like this 1-1-1 is result of Inside-Out development. (Not
saying bad in general.)


Point iv):

I agree that WUI and API has different needs and requirements for server
side may differ and colide but I would like to see WUI as "just" another API
client. Of course standard web page without full JS app needs to consume
HTML and often WUI displays bunch of (un)related things with current
resource but I am still on side with unified controllers for both WUI
and API.

--
Petr Blaho, pblaho at redhat.com
Software Engineer, CloudForms


More information about the aeolus-devel mailing list