[Pulp-dev] Single-Table Content API Changes, Performance Discussion

[Dennis Kliban]

On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley <dalley at redhat.com> wrote:

> 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.
>
>
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.

[0] https://pulp.plan.io/issues/4052


> Besides being a general update, I'd like to start a discussion 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?
>
> To clarify what I mean on that last point -- by "content type URLs" I mean
> that where you currently get back the url "
> /pulp/api/v3/repository_version/.../content/" under the "_content" field
> on a repoversion, you would instead get back something like
>
> { "pulp_file.filecontent":
> "/pulp/api/v3/content/file/files/?repository_version=.. }
>

I am +1 to making this change to our REST API.


>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181120/4d8b5044/attachment.htm>