In terms of removing POST /api/v3/repositories/<uuid>/versions/ from core, I want to bring it back to the MVP language and REST which drove the original design. The MVP has: "As an authenticated user, I can create a new version by adding or removing content to the latest version." To facilitate that in a generic way, we need a core endpoint to do that, i.e. /api/v3/repositories/<uuid>/versions/. My concern is that removing it would cause us to not fulfill our use cases without requiring more code from some plugin writers. Also in terms of REST philosophy, POSTing to the RespotoryVersion resource to create a new RepositoryVersion is the traditional url design.
For pulp_ansible, for example, the generic add/remove functionality at core endpoint ^ would be meet all of the pulp_ansible user's needs because of the way the pulp_ansible content is modelled. So removing this endpoint means more work for pulp_ansible developers w.r.t creating repo versions and providing tasks and endpoints. I don't see this extra responsibility on plugin writers coming with a clear benefit. One idea I liked in this discussion is to have a documented convention that encourages plugin writers to put their viewsets in a namespaced area. They still need the ability to put them anywhere due to live API goals/requirements so this would only be a convention for those tasks they are offering directly to their users. On Tue, Mar 27, 2018 at 5:40 PM, David Davis <davidda...@redhat.com> wrote: > I like Austin’s task proposal in that the plugin writers can focus on > serializers and tasks that can be easily integrated with core. That said, I > agree on the counterpoints raise about the new resource endpoints and > turning much of pulp into a task running system. So I am a bit mixed on > which approach is better. > > I do think that we should remove POST /api/v3/repositories/<uuid>/versions/ > from core. > > > David > > On Tue, Mar 27, 2018 at 3:49 PM, Austin Macdonald <amacd...@redhat.com> > wrote: > >> >>> - /api/v3/repositories/<uuid>/versions/ endpoint does not perform >>> plugin specific validation which can lead to "broken" repository >>> versions. >>> - Plugin authors don't have any convention to follow when creating >>> custom REST API endpoints for creating repository versions. >>> - As a result of ^, a user will have a hard time identifying >>> repository version creation APIs in different plugins. >>> >>> >> I agree with these points. >> >>> >>> - >>> >>> My first inclination is to disable the ability to POST to >>> /api/v3/repositories/<uuid>/versions/ and require users to use the >>> plugin specific APIs for creating repository versions. However, I think >>> that integrators of build systems that produce a variety of content types >>> would have a lot more flexibility if they could use a single generic API >>> endpoint to create a repository version independent of the content type. >>> >>> Let's continue this discussion by answering the following question: >>> >>> - Should we disable the ability to POST to >>> /api/v3/repositories/<uuid>/versions/ and require users to always >>> use a plugin specific repository version creation API? >>> >>> Yes, I think we should disable POST to /api/v3/repositories/<uuid>/ve >> rsions/ >> >> Simplifying integration is important, but we should not sacrifice >> correctness enforcement. >> >> _______________________________________________ >> 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
