Thanks for the feedback Martin. We have the same concerns, please see
comments below.
On 01/16/2013 06:09 AM, 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
Create a deployment is one the next items we are tackling with the API.
Callback support is also listed as an issue in github. More thinking
needs to go into this to make sure it is robust and usable.
All of the endpoints have an #index action. Did you mean something else
in (3)?
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.
Yes, I also would like to see the API be exercised by a client before we
cut a release. We intend to have the CLI perform this role.
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.
I don't disagree with you here. It is fine to diverge if a case presents
itself.
These are just IMHOs, but thanks for reading up to this point!
