[Pulp-dev] Pulp 3 REST API Challenges

Jeff Ortel jortel at redhat.com
Tue Apr 10 22:39:47 UTC 2018



On 04/10/2018 01:04 PM, Brian Bouterse wrote:
> These are good problem statements. I didn't understand all of the 
> aspects of it, so I put some inline questions.
>
> My overall question is: are these related problems? To share my answer 
> to this, I believe the first two problems are related and the third is 
> separate. The classic divide and conquor approach we could use here is 
> to confirm that the problems are unrelated and focus on resolving one 
> of them first.

Agreed.

>
>
> On Mon, Apr 9, 2018 at 3:18 PM, Austin Macdonald <austin at redhat.com 
> <mailto:austin at redhat.com>> wrote:
>
>     Folks,
>
>     Austin, Dennis, and Milan have identified the following issues
>     with current Pulp3 REST API design:
>
>       * Action endpoints are problematic.
>           o Example POST@/importers/<plugin>/sync/
>           o They are non-RESTful and would make client code tightly
>             coupled with the server code.
>           o These endpoints are inconsistent with the other parts of
>             the REST API.
>
> Is self-consistency really a goal? I think it's a placeholder for 
> consistency for REST since the "rest" of the API is RESTful. After 
> reading parts of Roy Fielding's writeup of the definition of REST I 
> believe "action endpoints are not RESTful" to be a true statement. 
> Maybe "Action endpoints are problematic" should be replaced with 
> "Action endpoints are not RESTful" perhaps and have the 
> self-consistency bullet removed?

Consistency in an API is always a valuable goal.

>           o DRF is not being used as intended for action endpoints so
>             we have to implement extra code. (against the grain)
>
> I don't know much about this. Where is the extra code?
>
>       * We don't have a convention for where plug-in-specific, custom
>         repository version creation endpoints.
>           o example POST@/api/v3/<where?>/docker/add/
>           o needs to be discoverable through the schema
>
> What does discoverable via the schema ^ mean? Aren't all urls listed 
> in the schema?
>
> I think of ^ problem somewhat differently. Yes all urls need to be 
> discoverable (a REST property), but isn't it more of an issue that the 
> urls which produce repo versions can't be identified distinctly from 
> any other plugin-contributed url? To paraphrase this perspective: 
> making a repo version is strewn about throughout the API in random 
> places which is a bad user experience. Is that what is motivation url 
> discovery?

Let me suggest another wording to "discovery".  The entire API needs to 
be clearly & completely defined in the schema.

>       * For direct repository version creation, plugins are not involved.
>           o validation correctness problem:
>             https://pulp.plan.io/issues/3541
>             <https://pulp.plan.io/issues/3541>
>           o example: POST@/api/v3/repositories/<repository_id>/versions/
>
> I agree with this problem statement. In terms of scope it affects some 
> plugin writers but not all.
>
>     We would like to get feedback on these issues being sound and
>     worth resolving before we resume particular solution discussion[1].
>
>     Thanks,
>     Austin, Dennis, and Milan
>
>     [1]
>     https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.html
>     <https://www.redhat.com/archives/pulp-dev/2018-March/msg00066.html>
>
>
>     _______________________________________________
>     Pulp-dev mailing list
>     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>     <https://www.redhat.com/mailman/listinfo/pulp-dev>
>
>
>
>
> _______________________________________________
> 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/20180410/c7ede1c7/attachment.htm>


More information about the Pulp-dev mailing list