[Pulp-dev] Proposal and feedback request: un-nest urls

[Jeremy Audet]

>
> Cons:
>
>    1. Lost investment in nesting.
>    2. Different structure than Pulp 2.
>
> The "lost investment in nesting" con isn't a con. This is an example of
the the "sunk cost" fallacy.

I don't think it matters much if our URL structure is different than in
Pulp 2. Pulp 3 is already massively different. This is a small detail
compared to the other changes being made. I don't think anyone will start
switching to Pulp 3 and suddenly shout "oh no, my API client doesn't work
because of the lack of nested paths!" If they do, the bigger issue is that
their API client is bad.

I've written some small API-focused applications in the past, and I've
found that nested URLs were problematic because they enforced strict
sub-set relationships that often became problematic in the future. For
example, if I have this URL structure:

/api/v1/people/{person_id}/items/{item_id}

...then it's easy to get info about the items a person has. But what if I
want to find out which of my party members has concentrated sprayflesh,
because a band of cloned delusional megalomaniacal robots is about to
successfully murder a teammate, and I need to heal them *now*? Do I need to
make four API calls?

GET /api/v1/people/1/items?name=Concentrated%20Sprayflesh
GET /api/v1/people/2/items?name=Concentrated%20Sprayflesh
GET /api/v1/people/3/items?name=Concentrated%20Sprayflesh
GET /api/v1/people/4/items?name=Concentrated%20Sprayflesh

Worse, let's say I'm a developer debugging an issue, and I want to find
every concentrated sprayflesh in the known world. Do I need to make several
thousand API calls? Both of these use cases are more elegantly solved by
allowing users to work directly with items, and by providing good filtering
support. This is based on my experience with some small old apps though,
and none of them went into production. Take it as you will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171116/44d6ea82/attachment.htm>