[Pulp-dev] Pulp api seemingly incompatible with generated bindings
Brian Bouterse
bbouters at redhat.com
Mon Apr 30 16:53:59 UTC 2018
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 <bkearney at 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 <jsherril at redhat.com
> > <mailto:jsherril at 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
> >> <jsherril at redhat.com <mailto:jsherril at 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
> >>> <dkliban at redhat.com <mailto:dkliban at 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
> >>> <jsherril at redhat.com <mailto:jsherril at 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 at redhat.com <mailto:Pulp-dev at redhat.com>
> >>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>> <https://www.redhat.com/mailman/listinfo/pulp-dev>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Pulp-dev mailing list
> >>> Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
> >>> https://www.redhat.com/mailman/listinfo/pulp-dev
> >>> <https://www.redhat.com/mailman/listinfo/pulp-dev>
> >>>
> >>>
> >>
> >>
> >
> >
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
> > https://www.redhat.com/mailman/listinfo/pulp-dev
> > <https://www.redhat.com/mailman/listinfo/pulp-dev>
> >
> >
> >
> >
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180430/5050526e/attachment.htm>
More information about the Pulp-dev
mailing list