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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
