RFC for buildpack registry search api #125
Conversation
elbandito
changed the title
elbandito
changed the title
|
|
||
| In addition, a server process will expose endpoints and handle incoming request for the GET endpoints mentioned earlier. For search requests, the text will be extracted from the `query` query parameter and used to search against the normalized buildpacks index. Results will be added to the server response, as a list of JSON objects. | ||
|
|
||
| *Note: The Distribution Team maintainers can manage this service, and could even set-up a pager (but only best effort, and during working hours). |
There was a problem hiding this comment.
we should add a note that it's explicitly out of scope.
elbandito
force-pushed
the
main
branch
2 times, most recently
from
4b9f399 to
f92893a
Compare
Signed-off-by: Travis <longoria.public@gmail.com>
Signed-off-by: Travis <longoria.public@gmail.com>
Signed-off-by: Travis <longoria.public@gmail.com>
Signed-off-by: Travis <longoria.public@gmail.com>
Signed-off-by: Travis <longoria.public@gmail.com>
elbandito
force-pushed
the
main
branch
3 times, most recently
from
e1c01e9 to
128103d
Compare
Signed-off-by: Travis <longoria.public@gmail.com>
|
|
||
| *Note: Initially, the Distribution Team maintainers can manage this service, and could even set-up a pager (but only best effort, and during working hours). In the future, we maybe able to extend this to other verified project contributors. | ||
|
|
||
| ### Future Work |
There was a problem hiding this comment.
We should add the idea of "tying" an API endpoint to a storage location here or under "What related issues do you consider out of scope for this RFC".
The use case in mind is:
If the user uses a buildpack registry that lives in some unofficial repo, how does a tool (such as
pack) know where to reach the API to search for buildpacks?
There was a problem hiding this comment.
I don't think we should be worried about pack trying to search unofficial registries at this time. There's no guarantee other registries will support the search API, and most unofficial registries (in the near future) will just be Git repos).
There was a problem hiding this comment.
I have UX concerns about this longterm but can see that we omit this for the time being until it's a little more proven and tested. ...With caution that we don't add constraints/assumptions that make this a lot harder to incorporate in the future.
|
|
||
| ### Future Work | ||
|
|
||
| - Query fields will be broken-up into separate, finer grained fields e.g. `ns`, `name`, and `yanked`. |
There was a problem hiding this comment.
I wonder if instead of breaking up query into fine-grained fields we want an exact match for params like ns. E.g. I can pass matches=function&ns=heroku to find all Heroku function buildpacks.
| Why should we *not* do this? | ||
| - more vulnerable due to Github outages | ||
| - less optimal than using actual DB technology | ||
| - constraint by what's in the index registry repository. We might want to augment the metadata, with new fields that don't makes sense to have in the index repository. I think this maybe an issue for the `/buildpacks/1` endpoint that *could* have download data, etc. things that don't belong in the actual repo. |
There was a problem hiding this comment.
Given we have non-indexed fields like description above is this drawback out of date, as we aren't tying ourselves strictly to the fields in the index?
|
|
||
| Retrieves all the buildpacks that satisfy the search query. If the response contains more than significant number of buildpacks, pagination will be used. The current approach to pagination is to take inspiration from how [Github](https://docs.github.com/en/free-pro-team@latest/rest/guides/traversing-with-pagination). | ||
| ``` | ||
| $ curl https://registry.buildpacks.io/v1/search?matches=projectriff |
There was a problem hiding this comment.
do we want to namespace this with "api", i.e. https://registry.buildpacks.io/v1/search?matches=projectriff? This way https://registry.buildpacks.io could be where the frontend lives.
There was a problem hiding this comment.
@hone like: api.registry.buildpacks.io or api.buildpacks.io?
There was a problem hiding this comment.
FWIW: From my systems management days, I like subdomain based routing plus it looks nice. +1 on https://api.buildpacks.io.
There was a problem hiding this comment.
This isn't really intended to be an api for all of buildpack.io though. I think it should be:
https://registry.buildpacks.io- frontendhttps://registry.buildpacks.io/api- API
There was a problem hiding this comment.
Yeah, I didn't want to presume this would be an API for all of buildpacks or what that means. At that point it'd be https://api.buildpacks.io/registry?
Signed-off-by: Travis <longoria.public@gmail.com>
Signed-off-by: Travis <longoria.public@gmail.com>
|
|
||
| ### Supported MIME types | ||
|
|
||
| `Accept: application/vnd.buildpacks+json` |
There was a problem hiding this comment.
awesome to see this. I imagine in the future we'll probably do something similar to what GitHub does.
|
Final Comment Period with merge disposition, closing on 24 December, 2020. |
|
@jkutner more realistically I imagine we'll close this Jan 6, 2021 when we're back from the break. |
No description provided.