<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">+1 on everything here.<br>
<br>
My only comments:<br>
<br>
Point 1)<br>
<br>
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?<br>
<br>
Ideally we would get feedback from existing customers and build a
priority list.<br>
<br>
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.<br>
<br>
Point iii)<br>
<br>
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.<br>
<br>
Point iv)<br>
<br>
+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.<br>
<br>
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. <br>
<br>
To me this makes sense on a couple levels. <br>
<ul>
<li>The UI guys can focus on what they do best "Building UIs",</li>
<li>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). <br>
</li>
<li>We can componentise the UI. Only deploy the bits of the UI
that people want + the API (for example self-service portal)<br>
</li>
<li>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.</li>
</ul>
<p>All IMHOs,<br>
</p>
<p>Thanks<br>
</p>
<p>Martyn<br>
</p>
<p><br>
</p>
<br>
<br>
On 01/16/2013 02:09 PM, Martin Povolny wrote:<br>
</div>
<blockquote cite="mid:20130116140912.GC9735@piskot.brq.redhat.com"
type="cite">
<pre wrap="">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!
</pre>
</blockquote>
<br>
</body>
</html>