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.
I'm not sure how using full, relative urls would or wouldn't resolve the bindings ID issue. I responded inline about IDs and hrefs too. On Mon, Apr 30, 2018 at 11:22 AM, Bryan Kearney <bkear...@redhat.com> wrote: > Is that true in practice? Most uses I see of APIs are around language > bindings where the url is not used as oftern. > 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. > > -- 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: > > https://www.w3.org/Provider/Style/URI > > > > 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 <jsher...@redhat.com > > <mailto:jsher...@redhat.com>> 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 > >> <jsher...@redhat.com <mailto:jsher...@redhat.com>> 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] https://www.redhat.com/archives/pulp-dev/2018- > January/msg00004.html > >>> <https://www.redhat.com/archives/pulp-dev/2018- > January/msg00004.html> > >>> [1] https://github.com/pulp/pulp_file/blob/ > 5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54 > >>> <https://github.com/pulp/pulp_file/blob/ > 5ffb33d8c70ffbb247aba8bf5b45633eba414b79/pulp_file/app/viewsets.py#L54> > >> > >> 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 > >>> <dkli...@redhat.com <mailto:dkli...@redhat.com>> 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 > >>> <jsher...@redhat.com <mailto:jsher...@redhat.com>> wrote: > >>> > >>> Hi All! > >>> > >>> I started playing around with pulp 3 and generated > >>> bindings via https://pulp.plan.io/issues/3580 > >>> <https://pulp.plan.io/issues/3580> 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": > >>> "http://localhost:8000/pulp/ > api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/ > >>> <http://localhost:8000/pulp/ > api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/>", > >>> "_latest_version_href": null, > >>> "_versions_href": > >>> "http://localhost:8000/pulp/ > api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/ > >>> <http://localhost:8000/pulp/ > api/v3/repositories/bfc61565-89b1-4b7b-9c4a-2ec91f299aca/versions/>", > >>> "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 > >>> Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com> > >>> https://www.redhat.com/mailman/listinfo/pulp-dev > >>> <https://www.redhat.com/mailman/listinfo/pulp-dev> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pulp-dev mailing list > >>> Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com> > >>> https://www.redhat.com/mailman/listinfo/pulp-dev > >>> <https://www.redhat.com/mailman/listinfo/pulp-dev> > >>> > >>> > >> > >> > > > > > > _______________________________________________ > > Pulp-dev mailing list > > Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com> > > https://www.redhat.com/mailman/listinfo/pulp-dev > > <https://www.redhat.com/mailman/listinfo/pulp-dev> > > > > > > > > > > _______________________________________________ > > Pulp-dev mailing list > > Pulp-dev@redhat.com > > https://www.redhat.com/mailman/listinfo/pulp-dev > > > > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev