<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">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_-5855491796607006020gmail-gE gmail-m_-5855491796607006020gmail-iv gmail-m_-5855491796607006020gmail-gt"><table class="gmail-m_-5855491796607006020gmail-cf gmail-m_-5855491796607006020gmail-gJ" cellpadding="0"><tbody><tr class="gmail-m_-5855491796607006020gmail-acZ gmail-m_-5855491796607006020gmail-xD"><td colspan="3"><table class="gmail-m_-5855491796607006020gmail-cf gmail-m_-5855491796607006020gmail-adz" cellpadding="0"><tbody><tr><td class="gmail-m_-5855491796607006020gmail-ady"></td></tr></tbody></table></td></tr></tbody></table></div><div id="gmail-m_-5855491796607006020gmail-:1ix"><div class="gmail-m_-5855491796607006020gmail-qQVYZb"></div><div class="gmail-m_-5855491796607006020gmail-utdU2e"></div><div id="gmail-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_-5855491796607006020gmail-"><div dir="ltr"><div id="gmail-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">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_-5855491796607006020gmail-"><div dir="ltr"><div id="gmail-m_-5855491796607006020gmail-m_-4136219612285385541m_6663064853145957797gmail-magicdomid28"></div><div id="gmail-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><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>