[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