<div dir="ltr"><div>I'm not necessarily against this but I'll recap some points I made on IRC:<br></div><div><br></div><div>The burden of knowing where to go to get that information would be pushed off onto the API user.  If we're not returning the URL, then anyone using the API must know that they need to query /pulp/api/v3/content/file/files/ (and likewise for every other content type), and that they need to use a filter for repository_version=... or repository_version_added=... and so so on.</div><div><br></div><div>I'm not sure how that would work, how that knowledge would be provided or if it's something that can be hardcoded into the bindings.  If you think that's possible, then I'm open to it.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 4:53 PM Dennis Kliban <<a href="mailto:dkliban@redhat.com">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 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_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-gE gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-iv gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-gt"><table class="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-cf gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-gJ" cellpadding="0"><tbody><tr class="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-acZ gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-xD"><td colspan="3"><table class="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-cf gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-adz" cellpadding="0"><tbody><tr><td class="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-ady"></td></tr></tbody></table></td></tr></tbody></table></div><div id="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-:1ix"><div class="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-qQVYZb"></div><div class="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-utdU2e"></div><div id="gmail-m_3153618078409597196gmail-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_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-"><div dir="ltr"><div id="gmail-m_3153618078409597196gmail-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_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-"><div dir="ltr"><div id="gmail-m_3153618078409597196gmail-m_-6350550413696576099m_-6336614354817582818gmail-m_-5855491796607006020gmail-m_-4136219612285385541m_6663064853145957797gmail-magicdomid28"></div><div id="gmail-m_3153618078409597196gmail-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" target="_blank">https://github.com/pulp/pulp/pull/3774</a></div><div>[1] <a href="https://github.com/pulp/pulp_file/pull/133" target="_blank">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>
</blockquote></div>