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

[Jeremy Audet]

>
> For deletes, the db relationships are all there, so I expect deletes to
>> cascade to other objects with any url
>> structure. I believe closer to the release, we'll have to look at the
>> cascading delete relationships to see if
>> the behaviors that we have are correct.
>>
>> Overall, I'm +1 on un-nesting. I think it would result in a good user
>> experience. I know it goes against the
>> logical composition arguments, which have been well laid out. We want
>> Pulp to be really simple, and the nested
>> URL in the top of this thread is anything but simple. Consider another
>> project like Ansible Galaxy (who also
>> uses Django and DRF). Their API is very flat and as an outsider I find it
>> very approachable:
>> https://galaxy.ansible.com/api/v1/  Pulp could be that simple.
>>
>
> Clicking through the Galaxy API, there seems to be a good bit of nesting.


There is. Let me be explicit. Here's some of the available URLs:

   - /api/v1/notifications/
   - /api/v1/notifications/120165/imports/
   - /api/v1/imports/
   - /api/v1/imports/166952/notifications/

In a filter-heavy world, they could be written as:

   - /api/v1/notifications/
   - /api/v1/imports/?notification=/api/v1/notifications/120165/
   - /api/v1/imports/
   - /api/v1/notifications/?import=/api/v1/imports/166952/

Or:

   - /api/v1/notifications/
   - /api/v1/imports/?notification__id=120165
   - /api/v1/imports/
   - /api/v1/notifications/?import__id=166952

...or something else.

There's more than one way to structure a RESTful HTTP API. I've had (very
limited) positive experiences with flattended out APIs, and like them
because they leave the door open to new use cases with little change. But
nested URLs are also perfectly valid, as evidenced by literature
<https://www.martinfowler.com/articles/richardsonMaturityModel.html> from
the likes of Martin Fowler.

I guess what I'm trying to say is: I think either approach is perfectly
valid, and concerns like "what do I find easy to conceptually understand"
or "what's easy to implement under the hood" are valid criteria for making
a choice.

2c from a non-dev. :-p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171130/1fc82b0a/attachment.htm>