Is that true in practice? Most uses I see of APIs are around language bindings where the url is not used as oftern.
-- 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 <[email protected] > <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> <https://www.redhat.com/mailman/listinfo/pulp-dev> >>> >>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> <https://www.redhat.com/mailman/listinfo/pulp-dev> >>> >>> >> >> > > > _______________________________________________ > Pulp-dev mailing list > [email protected] <mailto:[email protected]> > https://www.redhat.com/mailman/listinfo/pulp-dev > <https://www.redhat.com/mailman/listinfo/pulp-dev> > > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
