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

[David Davis]

We’ve exposed IDs and I think the next goal will be to somehow let Katello
use these IDs. I’ve opened a new story to solicit feedback on how this’ll
work:

https://pulp.plan.io/issues/3636


David

On Tue, May 1, 2018 at 9:14 AM, Brian Bouterse <bbouters at redhat.com> wrote:

>
> 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
>>
>>
>
> _______________________________________________
> 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/20180501/874752aa/attachment.htm>