[Pulp-dev] Pulp api seemingly incompatible with generated bindings

Brian Bouterse bbouters at redhat.com
Tue May 1 13:14:29 UTC 2018

On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney <bkearney at redhat.com> wrote:

> On 04/30/2018 04:08 PM, Brian Bouterse wrote:
> > @asmacdo, checking in on the why is great. I want to try to articulate
> > the benefits as I see them. Other perspectives and discussion are
> welcome.
> >
> > The design of using URLs for referring things is a design whose goal is
> > to minimize complexity as the # of resources grows. The Internet is a
> > useful analogy here. When someone wants to tell me how to find something
> > on Instagram, if the article's name is 'cat_pic432642' and that's all I
> > know, I'm going to have a hard time figuring out the actual URL to ask
> > Instagram's servers for, e.g. /thepostsarehere/cat_pic432642. Even if I
> > did know how Instram's url space was laid out, I have to think about it
> > different from all other web services I interact with; now they're all
> > different. This is the power of the URL itself. All clients and all
> > servers can use the uniform resource locator to refer to things. I think
> > this was the main contribution from Tim Berners-Lee that allowed him to
> > implement HTTP which has URIs at its heart.
> But, to Austins Point, if folks are going to interact with Pulp either
> from the cli or from Go|rust|python libraries, they will not see the
> urls. In your analogy, you would most likely google cat_pic432642  and
> never know the url you are going to.

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.

> -- bk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180501/b70eafe9/attachment.htm>

More information about the Pulp-dev mailing list