<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote:
<blockquote cite="mid:51360F2A.7010005@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 05/03/13 02:52 PM, Eric D Helms
wrote:<br>
</div>
<blockquote
cite="mid:CAFWK8FKhdQ30NbPeMP28Ns5eWFxSiZ2nxf-1v42zzoy+s0ob7Q@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Mar 5, 2013 at 9:11 AM,
Tomas Strachota <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:tstrachota@redhat.com" target="_blank">tstrachota@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 03/05/2013 02:29 PM, Eric D Helms
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On #2, if one of our core operating principles is
that nearly everything<br>
is scoped based on an organization, why would we
want to abstract that<br>
away and not make it explicit as part of resource
look-up? Given that a<br>
design goal of RESTful APIs is to be predictable, I
would think the form<br>
that includes organization at the trunk of the route
is more predictable<br>
and mimics how resources are structured.<br>
<br>
</blockquote>
<br>
</div>
The idea was not to get rid of the resource relations.
The scope would still be there for collections. For
example environments would look like:<br>
<br>
crate: POST /organization/ACME/<br>
list: GET /organization/ACME/environments/<br>
show: POST /environments/1/<br>
update: PUT /environments/1/<br>
destroy: DELETE /environments/1/<br>
<br>
I think of it like this:<br>
I want to see what environments I have in org ACME ->
I go to /organization/ACME/environments/. Now I know ids
of all the environments I'm interested in. If I want to
change it, I know it's environment so I go to
/environments/1/. I don't have to keep in mind what org
it's in.<br>
When whole api behaves the same I find it predictable.<br>
<br>
</blockquote>
<div style="">Given that the API is another user
interface, I feel that it's important for all our
interfaces to mimic one another in structure as well as
keep certain details in the forefront of users minds.
In the UI, most entities are scoped based on
Organization and this is expressed throughout the design
goals. This should, in my opinion, spill over into the
API so that resources are predictable and mimic other
workflows the user will be accustomed to. Using our
API, I should have to actively deal with the fact that
System A is a part of Org X to help me understand the
implications and because this is a built in hierarchy
that we've expressed as a guiding principle of our
design.</div>
</div>
</div>
</div>
</blockquote>
<br>
API doesn't have a concept of the 'current' organization, which is
another hint at the fact that API is used differently from UI.
Using organizations and environments as an example, a typical flow
would be:<br>
<br>
GET organizations/:id/environments <br>
PUT environments/:id<br>
<br>
The presence of the organization bit in the url would imply to me
that the environment id is unique within organization only (which
has its own consequences). As this is not the case here,
organization information isn't merely noise, it's misleading.<br>
</blockquote>
<br>
I think not having the org_id in the url makes our api much more
confusing today. For example, <br>
<br>
GET environments/ requires organization_id as a parameter, as
does <br>
POST environments/<br>
<br>
so the user is left guessing, does this require an org_id or not?
I also think the concept of "if the environment id is unique within
the org only or not" is moot, as the user does not define the id, so
why does he care under what scope is it unique? If the id was set
by the user that might be a valid point. <br>
<br>
-Justin<br>
<br>
<br>
<blockquote cite="mid:51360F2A.7010005@redhat.com" type="cite"> <br>
<blockquote
cite="mid:CAFWK8FKhdQ30NbPeMP28Ns5eWFxSiZ2nxf-1v42zzoy+s0ob7Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">I can understand your argument for
predictability, but if I start querying the collection
via /organization/ACME_Corporation/environments/, based
on the principles of REST, I would expect that I can
just add an ID to the end of that URL and acquire the
specific resource.</div>
</div>
</div>
</div>
</blockquote>
<br>
What principle[s] of REST do you refer to here?<br>
<br>
-d<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
katello-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:katello-devel@redhat.com">katello-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/katello-devel">https://www.redhat.com/mailman/listinfo/katello-devel</a></pre>
</blockquote>
<br>
</body>
</html>