<div dir="ltr"><div></div><div>Having full, relative urls returned would resolve the issues with the use case of changing the FQDN. I think it would also work with multi-host and container environments well. I agree w/ @thommckay's concerns about containers and full urls with FQDNs not working well. </div><div>I'm not sure how using full, relative urls would or wouldn't resolve the bindings ID issue. </div><div>I responded inline about IDs and hrefs too. </div><div> </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Apr 30, 2018 at 11:22 AM, Bryan Kearney <<a href="mailto:bkearney@redhat.com" target="_blank">bkearney@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is that true in practice? Most uses I see of APIs are around language bindings where the url is not used as oftern. </blockquote><div> In practice, using IDs instead of hrefs is common. I think REST motivates us towards the detail resource full, relative path being the universal descriptor of that resource. If we start referring to a detail resource by its ID only (not full relative path) then we tightly couple the client and server which gives back some of the benefits of REST. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -- bk On 04/30/2018 11:13 AM, Brian Bouterse wrote: > +1 to fixing whatever the issue that prevents the built bindings from > working. If David's proposal does that then +1. > > I want to share an opinion on continuing with the use of urls (in > addition perhaps to ids) and not supporting rerooting a Pulp deployment. > Using hrefs is valuable in the response and the requests because the > client doesn't have to understand what resource type they should use for > a given object being referenced. In practice you can open the next > resource without any url parsing/forming. In terms of rerooting an > application, it will break clients. It reminds me of this W3C page I > read which suggests that great URIs are expected to never change: > <a href="https://www.w3.org/Provider/Style/URI" rel="noreferrer" target="_blank">https://www.w3.org/Provider/Style/URI</a> > > I hope we can fix the bindings asap. Sorry they aren't working. Thank > you for reporting this via the list. > > > > On Mon, Apr 30, 2018 at 10:24 AM, Justin Sherrill <<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a> > <mailto:<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a>>> wrote: > > > > On 04/30/2018 10:05 AM, David Davis wrote: >> So what I’d probably propose is exposing the UUIDs in the response >> and then extending HyperlinkedRelatedFields to accept UUID or >> href. Then third parties like Katello could store and just use >> UUIDs (and not worry about hrefs). >> >> 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. > > It matters if you are a client and are fetching stored hrefs. > > Justin > > >> >> >> David >> >> On Mon, Apr 30, 2018 at 9:58 AM, Justin Sherrill <div><div class="h5">>> <<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a> <mailto:<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a>>> wrote: >> >> >> >> On 04/27/2018 07:18 PM, David Davis wrote: >>> 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? >> >> 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. >> >>> >>> 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]). >>> >>> [0] <a href="https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html" rel="noreferrer" target="_blank">https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html</a> >>> <<a href="https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html" rel="noreferrer" target="_blank">https://www.redhat.com/archives/pulp-dev/2018-January/msg00004.html</a>> >>> [1] <a href="https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54" rel="noreferrer" target="_blank">https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54</a> >>> <<a href="https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54" rel="noreferrer" target="_blank">https://github.com/pulp/pulp_file/blob/5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54</a>> >> >> Could you explain a bit about this? >> >> In order to use pulp 3 then, i'd guess we would either need to: >> >> 1) store ALL hrefs about all objects >> 2) fetch an object before we can do anything with it >> >> Or am i missing an option 3? >> >> 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. >> >> Justin >> >>> >>> >>> >>> David >>> >>> On Fri, Apr 27, 2018 at 4:29 PM, Dennis Kliban </div></div>>>> <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a> <mailto:<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>>> wrote: >>> >>> I can't remember why we decided to remove UUID from the >>> responses. It sounds like we should add them back. >>> >>> On Fri, Apr 27, 2018 at 12:26 PM, Justin Sherrill <div><div class="h5">>>> <<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a> <mailto:<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a>>> wrote: >>> >>> Hi All! >>> >>> 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/3580</a> >>> <<a href="https://pulp.plan.io/issues/3580" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/3580</a>> and it results >>> somewhat in what you would expect. Here's an example: >>> >>> # @param id A UUID string identifying this >>> repository. >>> # @param [Hash] opts the optional parameters >>> # @return [Repository] >>> def repositories_read(id, opts = {}) >>> data, _status_code, _headers = >>> repositories_read_with_http_info(id, opts) >>> return data >>> end >>> >>> >>> Notice that the UUID is to be passed in. When >>> creating a repository, i only get the _href: >>> >>> { >>> "_href": >>> "<a href="http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/" rel="noreferrer" target="_blank">http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/</a> >>> <<a href="http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/" rel="noreferrer" target="_blank">http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/</a>>", >>> "_latest_version_href": null, >>> "_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/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/</a> >>> <<a href="http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/" rel="noreferrer" target="_blank">http://localhost:8000/pulp/api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/</a>>", >>> "created": "2018-04-27T15:26:03.546956Z", >>> "description": "", >>> "name": "test", >>> "notes": {} >>> } >>> >>> 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? >>> >>> Justin >>> >>> _______________________________________________ >>> Pulp-dev mailing list </div></div>>>> <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>> >>> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> >>> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>> >>> >>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>> >>> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> >>> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>> >>> >>> >> >> > > > _______________________________________________ > Pulp-dev mailing list > <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <mailto:<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> <div class="HOEnZb"><div class="h5">> <<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>> > > > > > _______________________________________________ > Pulp-dev mailing list > <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> > </div></div></blockquote></div> </div></div>