<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 12:31 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>> wrote:<br></div><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 dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>> wrote:<br></div><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 class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-gE gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-iv gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-gt"><table class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-cf gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-gJ" cellpadding="0"><tbody><tr class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-acZ gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-xD"><td colspan="3"><table class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-cf gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-adz" cellpadding="0"><tbody><tr><td class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-ady"></td></tr></tbody></table></td></tr></tbody></table></div><div id="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-:1ix"><div class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-qQVYZb"></div><div class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-utdU2e"></div><div id="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-m_-4136219612285385541m_6663064853145957797gmail-magicdomid27"><span>Some of the API changes that are required by single-table-content would be beneficial even if we didn't go forwards with the modelling changes. For instance, currently we have single endpoints for each of repository_version/.../content/, .../added_content/, and .../removed_content/ which mix content of all types together. This makes it impossible for clients to expect the data returned to expect any particular schema. What the single-table-content does is to provide separate query urls for each content type present in the repository version, which I believe is a usability win for us, and it's something we could implement without using any of the modelling changes.</span></div></div><div class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-"><div dir="ltr"><div id="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-m_-4136219612285385541m_6663064853145957797gmail-magicdomid28"><br></div></div></div></div></blockquote><div><br></div><div>The current behavior of the 'content' APIs is already causing a problem for our OpenAPI 2.0 schema. OpenAPI 2.0 does not support polymorphic responses. We are currently tracking problem with a bug[0]. The only way to resolve this problem is to provide APIs that return heterogeneous types. <br></div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/4052" target="_blank">https://pulp.plan.io/issues/4052</a><br></div><div> </div><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 class="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-"><div dir="ltr"><div id="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-m_-4136219612285385541m_6663064853145957797gmail-magicdomid28"></div><div id="gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-m_-4136219612285385541m_6663064853145957797gmail-magicdomid29"><span>Besides being a general update, </span><span>I'd like to start a discussion</span><span> to understand: is changing the Pulp 3 API so that it's organized around content type URLs OK with everyone? This resolves the usability issues of returning mixed types. Are there any downsides with this approach?</span></div><div><span><br></span></div><div><span>To clarify what I mean on that last point -- by "content type URLs" I mean that where you currently get back the url "<span>/pulp/api/v3/repository_version/.../content/</span>" under the "_content" field on a repoversion, you would instead get back something like <br></span></div><div><span><br></span></div><div><span>{ "pulp_file.filecontent": "/pulp/api/v3/content/file/files/?repository_version=.. }</span></div></div></div></div></blockquote><div><br></div><div>I am +1 to making this change to our REST API.</div></div></div></div></blockquote><div><br></div><div>Thank you Daniel for putting together the patches[0,1] to make these changes possible. I've had a chance to try out the Python bindings. When using the bindings, I discovered that I could not do anything with the URLs returned for each content type added or removed. Making the request to those URLs requires making a call that looks like this:</div><div><br></div><div>api.content_file_files_list(repository_version_added=repository_version_1.href)<br></div><div><br></div><div>What if instead the API returned the number of each content type added or removed. So a repository version response would look like:</div><div><br></div><div>{'base_version': None,<br> 'content_added': {'<span>pulp_file.</span>file': 4},<br> 'content_removed': {'<span>pulp_file.</span>file': 1},<br> 'content_summary': {'<span>pulp_file.</span>file': '3'},<br> 'created': datetime.datetime(2018, 12, 5, 23, 34, 26, 948749, tzinfo=tzlocal()),<br> 'href': '/pulp/api/v3/repositories/4/versions/1/',<br> 'number': 1}</div><div><br></div><div>Thoughts?<br></div><div><br></div><div>[0] <a href="https://github.com/pulp/pulp/pull/3774">https://github.com/pulp/pulp/pull/3774</a></div><div>[1] <a href="https://github.com/pulp/pulp_file/pull/133">https://github.com/pulp/pulp_file/pull/133</a><br></div><div><br></div><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 dir="ltr"><div class="gmail_quote"><div> </div><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"><br></div> _______________________________________________<br> Pulp-dev mailing list<br> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br> </blockquote></div></div></div> </blockquote></div></div></div></div></div></div>