<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_1766863806553026546h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul><li>We don't have a convention for
where plug-in-specific, custom
repository version creation
endpoints.<br>
</li>
<ul>
<li>example
POST@/api/v3/<where?>/docker/a<wbr>dd/</li>
<li>needs to be discoverable
through the schema</li>
</ul>
</ul>
</div>
</div>
</blockquote>
</span>
<div>What does discoverable via the schema ^
mean? Aren't all urls listed in the
schema?<br>
<br>
</div>
<div>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?<br>
</div>
<span>
<div> </div>
</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. I envision a CLI that can discover new plugin
repository-version-creating functionality without having
to install new client packages. Allowing plugin writers to
add endpoints in arbitrary places for creating repository
versions will make it impossible for the client to know
what all the possible ways of creating a repository
version are.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Currently plugins can provide one (or more) arbitrary endpoints to
perform sync which is one form of creating a repository version.
How is the endpoint for creating a version by adding content any
different?<span><br>
<br></span></div></blockquote><div><br></div></div></div><div>I don't understand the question.<br><br>Right now plugin writers can add REST API endpoints that create repository versions anywhere they want. This means the client has to inspect all of the API schema to find all the different ways to create a repository version. I would like to make this discovery process simpler for the client. It would be best if the client could learn about all the ways to create a repository version by making a single request to the API. <br></div></div></div></div></blockquote><div><br></div><div>"Custom repository version creation endpoints need to be discoverable through the schema."</div><div><br></div><div>We have some different ideas for how to implement this goal, and I think that is coloring our perception of the problem as well. The statement is vague, but we chose it so we could show what we agree on despite having subtly different views.</div><div><br></div><div>The weakest interpretation of the statement is that every API endpoint is documented in the schema. I doubt that anyone would disagree with that. In case it isn't clear already, I want to restate that the scope of this point is limited to endpoints that create repository versions and publications. (sync, add, publish, complex copy, etc). Within that scope, I look at "discoverability" as related to the consistency issue.</div><div><br></div><div>If we have a logical, consistent API, then users (including client users) should be able to guess what the endpoint (or command) should be for a given use case. This also includes the need for docs readers to have a good idea where to find their information. That would obviously be difficult to do with these endpoints spread all around the API. Dennis takes this a step farther, suggesting that <i>any</i> action that creates a repository version, regardless of plugin should be on a single endpoint. I suggest that grouping them by plugin is enough. Obviously, this gets into the implementation details a bit, so I don't want to get too much in the weeds until we are back to discussing concrete proposals.</div></div></div></div>