<div dir="ltr">I have a first-draft of the POC <a href="https://github.com/pulp/pulp/pull/3232">https://github.com/pulp/pulp/pull/3232</a><div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 30, 2017 at 6:23 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For deletes, the db relationships are all there, so I expect deletes to cascade to other objects with any url<br>structure. I believe closer to the release, we'll have to look at the cascading delete relationships to see if<br>the behaviors that we have are correct.<br><br>Overall, I'm +1 on un-nesting. I think it would result in a good user experience. I know it goes against the<br>logical composition arguments, which have been well laid out. We want Pulp to be really simple, and the nested<br>URL in the top of this thread is anything but simple. Consider another project like Ansible Galaxy (who also<br>uses Django and DRF). Their API is very flat and as an outsider I find it very approachable:<br><a href="https://galaxy.ansible.com/api/v1/" target="_blank">https://galaxy.ansible.com/<wbr>api/v1/</a>  Pulp could be that simple.<br></blockquote><br>Clicking through the Galaxy API, there seems to be a good bit of nesting.</blockquote><div><br></div></span><div>There is. Let me be explicit. Here's some of the available URLs:</div><ul><li>/api/v1/notifications/</li><li>/api/v1/notifications/120165/<wbr>imports/</li><li>/api/v1/imports/</li><li>/api/v1/imports/166952/<wbr>notifications/</li></ul></div></div></div></blockquote><div>A simple call to the repository gives hrefs for importers and publishers, so I think we are covered.</div><div>Example from POC:</div><div><br></div><div>GET /api/v3/repositories/a6287821-5d13-4a59-8a34-a7ea98bcc40d/</div><div><br></div><div><br></div><div>Response:</div><div>{</div><div>    "_href": "<a href="http://pulp3.dev:8000/api/v3/repositories/a6287821-5d13-4a59-8a34-a7ea98bcc40d/">http://pulp3.dev:8000/api/v3/repositories/a6287821-5d13-4a59-8a34-a7ea98bcc40d/</a>",</div><div>    "name": "test",</div><div>    "description": "",</div><div>    "notes": {},</div><div>    "last_content_added": null,</div><div>    "last_content_removed": null,</div><div>    "importers": [</div><div>        "<a href="http://pulp3.dev:8000/api/v3/importers/file/testi/">http://pulp3.dev:8000/api/v3/importers/file/testi/</a>"   <--------------------<</div><div>    ],</div><div>    "publishers": [</div><div>       "<a href="http://pulp3.dev:8000/api/v3/publishers/file/testp/">http://pulp3.dev:8000/api/v3/publishers/file/testp/</a>", <----------------------<</div><div>        "<a href="http://pulp3.dev:8000/api/v3/publishers/file/sdfdsffd/">http://pulp3.dev:8000/api/v3/publishers/file/sdfdsffd/</a>"</div><div>    ],</div><div>    "content": "<a href="http://pulp3.dev:8000/api/v3/repositories/a6287821-5d13-4a59-8a34-a7ea98bcc40d/content/">http://pulp3.dev:8000/api/v3/repositories/a6287821-5d13-4a59-8a34-a7ea98bcc40d/content/</a>",</div><div>    "content_summary": {}</div><div>}</div><div><br></div><div>It seems a little redundant, but we could also add "detail routes" to the repository (and/or importers/publishers) that would add these endpoints. (We would need to decide if we cast() or if we add <type> to the endpoint.)</div><div><br></div><div>v3/repositories/<id>/importers/</div><div>v3/repositories/<id>/publishers/</div><div><div><br></div></div><div><br></div></div></div></div></div>