<div dir="ltr"><div><div>@asmacdo, checking in on the why is great. I want to try to articulate the benefits as I see them. Other perspectives and discussion are welcome.<br><br>The design of using URLs for referring things is a design whose goal is to minimize complexity as the # of resources grows. The Internet is a useful analogy here. When someone wants to tell me how to find something on Instagram, if the article's name is 'cat_pic432642' and that's all I know, I'm going to have a hard time figuring out the actual URL to ask Instagram's servers for, e.g. /thepostsarehere/cat_pic432642. Even if I did know how Instram's url space was laid out, I have to think about it different from all other web services I interact with; now they're all different. This is the power of the URL itself. All clients and all servers can use the uniform resource locator to refer to things. I think this was the main contribution from Tim Berners-Lee that allowed him to implement HTTP which has URIs at its heart.<br><br></div>To bring it back to Pulp, what we have in Pulp avoids complexity the same way. The nice part is that we can generically process the input from the client, i.e. a URL, into the model object. To start accepting IDs instead of URLs then the server code now needs to know the classpath (hard coded) for every argument received. This is the complexity we get to avoid via URIs versus IDs.<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 3:35 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:austin@redhat.com" target="_blank">austin@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 dir="ltr">I'm not sure how we should handle this, but I have a value question.<div><br></div><div>Our CLI and Bindings will be autogenerated, so they will always have the full functionality of the REST API. Is there a reason our users would use the REST API directly? If the REST API is only used through the bindings/cli, what is the benefit of being HATEOAS compliant?</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 30, 2018 at 3:21 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@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 text="#000000" bgcolor="#FFFFFF"><span>
<br>
<br>
<div class="m_3992266438970053186m_4600827657191702380moz-cite-prefix">On 04/30/2018 09:05 AM, David Davis
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">So what I’d probably propose is exposing the UUIDs
in the response and then extending HyperlinkedRelatedFi<wbr>elds
to accept UUID or href. Then third parties like Katello could
store and just use UUIDs (and not worry about hrefs).</div>
</blockquote>
<br></span>
+1 to exposing/supporting both the PKs and hrefs. Btw: We should be
talking in terms of resource PKs (primary keys) or IDs instead of
UUIDs for clarity.<div><div class="m_3992266438970053186h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Regarding hrefs though, hostname and port don’t matter. The
app just looks at the relative path. It looks like changing
the deployment path causes problems though.</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
</div>
<div>David<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Apr 30, 2018 at 9:58 AM,
Justin Sherrill <span dir="ltr"><<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@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 text="#000000" bgcolor="#FFFFFF"><span>
<p><br>
</p>
<br>
<div class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780m_-4357389800984273450moz-cite-prefix">On
04/27/2018 07:18 PM, David Davis wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I’m not sure how returning UUIDs in
our responses helps Katello. In our previous
conversation, it was concluded that Katello should
use the hrefs[0]. Why expose UUIDs if Katello is
not going to store them?</div>
</blockquote>
<br>
</span> And thats fine, but bindings are pointless at
that point, so pulp shouldn't really advertise them as a
feature. This seemed to have been 'talked up' quite a
bit as a feature, but is completely unusable. <br>
<span> <br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Katello could store/use UUIDs but then it's
going to run into problems when dealing with
parameters that are hrefs (such as
repository_version for publishing[1]).<br>
<div><br>
</div>
<div>[0] <a href="https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html" target="_blank">https://www.redhat.com/arc<wbr>hives/pulp-dev/2018-January/ms<wbr>g00004.html</a></div>
</div>
<div>[1] <a href="https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54" target="_blank">https://github.com/pulp/pu<wbr>lp_file/blob/5ffb33d8c70ffbb24<wbr>7aba8bf5b45633eba414b79/pulp_f<wbr>ile/app/viewsets.py#L54</a></div>
</div>
</blockquote>
<br>
</span> Could you explain a bit about this?<br>
<br>
In order to use pulp 3 then, i'd guess we would either
need to:<br>
<br>
1) store ALL hrefs about all objects<br>
2) fetch an object before we can do anything with it<br>
<br>
Or am i missing an option 3?<br>
<br>
On a side note, the href's seem to include
hostname/port/deployment path. This seems incompatible
with things like hostname changes. We can fairly easily
just chomp off only the path, but if i were a user and
had stored all these hrefs, i would be very unhappy if i
had all the full href's stored.<span class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780HOEnZb"><font color="#888888"><br>
<br>
Justin</font></span>
<div>
<div class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div class="gmail_extra"><br>
<div>
<div class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780m_-4357389800984273450m_6069296669486595901gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
</div>
<div>David<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Fri, Apr 27, 2018
at 4:29 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div dir="ltr">I can't remember why we
decided to remove UUID from the
responses. It sounds like we should add
them back. <br>
</div>
<div class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780m_-4357389800984273450m_6069296669486595901HOEnZb">
<div class="m_3992266438970053186m_4600827657191702380m_-1335252507536294780m_-4357389800984273450m_6069296669486595901h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Apr
27, 2018 at 12:26 PM, Justin
Sherrill <span dir="ltr"><<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">Hi
All!<br>
<br>
I started playing around with
pulp 3 and generated bindings
via <a href="https://pulp.plan.io/issues/3580" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/35<wbr>80</a>
and it results somewhat in what
you would expect. Here's an
example:<br>
<br>
# @param id A UUID string
identifying this repository.<br>
# @param [Hash] opts the
optional parameters<br>
# @return [Repository]<br>
def repositories_read(id,
opts = {})<br>
data, _status_code,
_headers =
repositories_read_with_http_in<wbr>fo(id,
opts)<br>
return data<br>
end<br>
<br>
<br>
Notice that the UUID is to be
passed in. When creating a
repository, i only get the
_href:<br>
<br>
{<br>
"_href": "<a href="http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/" rel="noreferrer" target="_blank">http://localhost:8000/pulp/ap<wbr>i/v3/repositories/bfc61565-89b<wbr>1-4b7b-9c4a-2ec91f299aca/</a>",<br>
"_latest_version_href":
null,<br>
"_versions_href": "<a href="http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/" rel="noreferrer" target="_blank">http://localhost:8000/pulp/ap<wbr>i/v3/repositories/bfc61565-89b<wbr>1-4b7b-9c4a-2ec91f299aca/versi<wbr>ons/</a>",<br>
"created":
"2018-04-27T15:26:03.546956Z",<br>
"description": "",<br>
"name": "test",<br>
"notes": {}<br>
}<br>
<br>
Meaning, there's really no way
to use this specific binding
with the return format for
pulp. I imagine most binding
generation would be expecting
the user to know the ID of the
objects and not work off of
_hrefs. Any reason to not
include the IDs in the response?<br>
<br>
Justin<br>
<br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="m_3992266438970053186m_4600827657191702380mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="m_3992266438970053186m_4600827657191702380moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="m_3992266438970053186m_4600827657191702380moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>