<div dir="ltr"><div>I'm concerned that we haven't been very intentional with the introduction of 'id' to our API. We added 'id' in a hurry as a stop-gap due to a lack of bindings, now bindings are available that don't require id, but we still have 'id'. We should remove 'id'. The CLI is the only place I know that is using it so these are CLI questions:<br></div><div><br></div><div>How is a user referring to repository f20487e5-51c4-47c7-af22-633adc<wbr>4bffa9 easier/better than repositories/f20487e5-51c4-47c<wbr>7-af22-633adc4bffa9 or <a href="http://localhost:8000/pulp/api/v3/repositories/f20487e5-51c4-47c7-af22-633adc4bffa9/" target="_blank">http://localhost:8000/pulp/api<wbr>/v3/repositories/f20487e5-51c4<wbr>-47c7-af22-633adc4bffa9/</a> for users? Users will have to copy the UUID anyway, they can just copy the URL instead. Also they could just a portion of the URL (no fqn or prefix is needed). AIUI the API treats a reference to <a href="http://localhost:8000/pulp/api/v3/repositories/f20487e5-51c4-47c7-af22-633adc4bffa9/" target="_blank">http://localhost:8000/pulp/api<wbr>/v3/repositories/f20487e5-51c4<wbr>-47c7-af22-633adc4bffa9/</a> and repositories/f20487e5-51c4-47c<wbr>7-af22-633adc4bffa9 as the same since API prefixes are stripped off by DRF.<br></div><div><br></div><div>From a usability perspective, when CLI users are referring to objects, why wouldn't users use a more useful term like its name instead? Users this way would use 'name=foo' and internally the CLI would just figure it out by making requests to resolve that 'name=foo' to a specific object 'foo'. Even if 'name' is mutable, at the time the user runs it it won't be ambiguous.<br></div><div><br></div><div>What would it take for us to remove 'id' once again? I advocate that we should not have 'two ways' to refer to objects.<br></div><div><br></div><div>@jsherrill this is a complete aside from your important question about who will maintain the swagger add-on code. I think the Pulp community needs those bindings and so the Pulp community will maintain that add-on code for those bindings. I don't expect Katello to maintain Pulp's Ruby bindings. If you've found a bug in the Ruby bindings can you file it in Pulp and link to it?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 9, 2018 at 9:34 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Pulp 3 CLI relies on the id field as it provides a an immutable way for users to identify objects without using hrefs which wouldn’t make sense in a CLI. So I think we’re keeping the id field. <div><br></div><div>That said, I don’t see how it helps Katello unless Katello stores and uses the id field to identify objects instead of hrefs?<div><div class="m_6294101771746101026m_-441703248435732673m_-557816623888173119h5"><br><br>On Monday, July 9, 2018, Justin Sherrill <<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@redhat.com</a>> 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">
<p>Hi all,</p>
<p>I finally had some time to play with these and I do have some
concerns. First i'd say that Dennis' work to get the swagger
generation working with href's seemed to work really well! I did
find one small bug(1) that may be isolated to the ruby bindings,
but seems like a serialization issue potentially.<br>
</p>
<p>However I do have some concerns. According to Dennis, upstream
swagger does not seem open to accepting this change that utilizes
href's in its api calls. This leaves us all in a bit of a pickle
as:</p>
<p>1) pulp seems to suggest to use hrefs (and may remove ids in the
future?) <br>
2) swagger does not (and will never?) support referencing objects
by href's in the future</p>
<p>Thus for katello to use href's, we would need to use an altered
version of swagger that someone maintains. While the patch is
small, I'm not sure either of our teams are super well positioned
to maintain something like this long term. <br>
</p>
<p>It might make sense for the pulp team to maintain this, as the
requirements are being suggested by the pulp team, however it
doesn't seem like ya'll will actually be using any generated
bindings which doesn't seem like a good dependency. <br>
</p>
<p>It might make sense for the Katello team but I would say we're
only using hrefs because they seem to be what was recommended. In
both cases its a different technology (java) with a different
built system. I could see 3 years from now some issue coming up
that requires us to update to a newer swagger version and untangle
this when no one that was involved in this decision was around. I
don't really see either of our teams maintaining a fork of the
swagger code generation as a good long term solution.<br>
</p>
<p>May I suggest that we either:</p>
<p> a) Work harder to get the code change upstream</p>
<p>or if that does not seem to be going well<br>
</p>
<p> b) commit to continue responding with ids (in addition to hrefs)
in all object responses</p>
<p>(1) <a href="https://pulp.plan.io/issues/3843" target="_blank">https://pulp.plan.io/issues/38<wbr>43</a><br>
</p>
<br>
<div>On 05/17/2018 06:26 PM, Dennis Kliban
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I have been able modify the default behavior of
swagger-codegen to produce bindings that use relative URLs to
identify resources. The required changes can be seen here[0].
The compiled jar is available for download here[1]. <br>
<br>
The following command can be used to generate python bindings.
Replace 'python' with 'ruby' and you'll get ruby bindings. The
json file is the API schema returned by the Pulp server at <a href="http://localhost:8000/api/v3/docs/api.json" target="_blank">http://localhost:8000/api/v3/d<wbr>ocs/api.json</a>.
<br>
<br>
java -jar ./swagger-codegen-cli.jar generate -i
~/Downloads/pulp3-api.json -l python -o some_directory_name<br>
<br>
[0] <a href="https://github.com/dkliban/swagger-codegen/commit/e31e96769864b73b06bd99f5e20e4720562539b9" target="_blank">https://github.com/dkliban/swa<wbr>gger-codegen/commit/e31e967698<wbr>64b73b06bd99f5e20e4720562539b9</a><br>
[1] <a href="https://repos.fedorapeople.org/pulp/pulp/swagger/swagger-codegen-cli.jar" target="_blank">https://repos.fedorapeople.org<wbr>/pulp/pulp/swagger/swagger-cod<wbr>egen-cli.jar</a><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 1, 2018 at 11:18 AM, David
Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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">We’ve exposed IDs and I think the next goal
will be to somehow let Katello use these IDs. I’ve opened
a new story to solicit feedback on how this’ll work:
<div><br>
</div>
<div><a href="https://pulp.plan.io/issues/3636" target="_blank">https://pulp.plan.io/issues/36<wbr>36</a><span><font color="#888888"><br>
</font></span></div>
</div>
<div class="gmail_extra"><span><font color="#888888"><br clear="all">
<div>
<div 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>
</font></span>
<div class="gmail_quote">
<div>
<div>On Tue, May 1, 2018 at 9:14 AM, Brian
Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Tue, May 1,
2018 at 7:59 AM, Bryan Kearney <span dir="ltr"><<a href="mailto:bkearney@redhat.com" target="_blank">bkearney@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On
04/30/2018 04:08 PM, Brian Bouterse
wrote:<br>
> @asmacdo, checking in on the why
is great. I want to try to articulate<br>
> 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<br>
> to minimize complexity as the #
of resources grows. The Internet is a<br>
> useful analogy here. When someone
wants to tell me how to find something<br>
> on Instagram, if the article's
name is 'cat_pic432642' and that's all
I<br>
> know, I'm going to have a hard
time figuring out the actual URL to
ask<br>
> Instagram's servers for, e.g.
/thepostsarehere/cat_pic432642<wbr>.
Even if I<br>
> did know how Instram's url space
was laid out, I have to think about it<br>
> different from all other web
services I interact with; now they're
all<br>
> different. This is the power of
the URL itself. All clients and all<br>
> servers can use the uniform
resource locator to refer to things. I
think<br>
> this was the main contribution
from Tim Berners-Lee that allowed him
to<br>
> implement HTTP which has URIs at
its heart.<br>
<br>
</span>But, to Austins Point, if folks
are going to interact with Pulp either<br>
from the cli or from Go|rust|python
libraries, they will not see the<br>
urls. In your analogy, you would most
likely google cat_pic432642 and<br>
never know the url you are going to.<br>
</blockquote>
</span>
<div><br>
I agree there will be much binding-based
usage, and CLI usage, but there will
always be users who will use httpie with
some bash scripting calls instead. So from
that perspective, the goals remain the
same they have for years; we need to put
forth the best, lowest-complexity REST
API.<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
-- bk<br>
<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
<br>
</div>
</div>
<span>______________________________<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>
</span></blockquote>
</div>
<br>
</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>
<br>
<fieldset></fieldset>
<br>
<pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a 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>
</blockquote></div></div></div><span class="m_6294101771746101026m_-441703248435732673m_-557816623888173119HOEnZb"><font color="#888888"><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div><br>
</font></span><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>