On Tue, Nov 20, 2018 at 12:31 PM Dennis Kliban <dkli...@redhat.com> wrote:
> On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley <dal...@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. > 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: api.content_file_files_list(repository_version_added=repository_version_1.href) What if instead the API returned the number of each content type added or removed. So a repository version response would look like: {'base_version': None, 'content_added': {'pulp_file.file': 4}, 'content_removed': {'pulp_file.file': 1}, 'content_summary': {'pulp_file.file': '3'}, 'created': datetime.datetime(2018, 12, 5, 23, 34, 26, 948749, tzinfo=tzlocal()), 'href': '/pulp/api/v3/repositories/4/versions/1/', 'number': 1} Thoughts? [0] https://github.com/pulp/pulp/pull/3774 [1] https://github.com/pulp/pulp_file/pull/133 > >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev