On Tue, May 1, 2018 at 7:59 AM, Bryan Kearney <[email protected]> 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 [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
