-
Notifications
You must be signed in to change notification settings - Fork 3
Registry API specification #17
Comments
Let's start off with requirements we have for the API. Guarantees
Functionality
Other considerations and open questions
Any comments so far? |
Based on the above requirements, I'd propose an URL scheme as follows, in python pseudocode: # The URL we need when adding a new registry. Can be any arbitrary URL.
BASE_API_URL = "https://example.org/registry"
# API URLs are formed with <base_url>/<api_version>/<endpoint>
URLS = (
# POST, Obtaining an authentication token
f"{BASE_API_URL}/v1/token/"
# GET, Listing all packages.
# Possible search and filtering could be done with GET parameters here
# Pagination support possibly?
f"{BASE_API_URL}/v1/packages/"
# POST, Uploading a new package, requires an authentication token
f"{BASE_API_URL}/v1/packages/"
# GET, Showing details of version 1.0.0 of package "SomePackage" by author "AuthorName"
f"{BASE_API_URL}/v1/packages/AuthorName/SomePackage/1.0.0/"
# GET, Download version 1.0.0. of package "SomePackage" by author "AuthorName"
f"{BASE_API_URL}/v1/packages/AuthorName/SomePackage/1.0.0/download/"
) Users then could add the registry to their GPM configuration (assuming it doesn't exist there yet) e.g. with gpm registry add example https://example.org/registry For listing packages from this registry, GPM would then query |
If searching is going to be potentially implemented, might I suggest a I suppose you could just search within the Or, restructure the routes.
// Returns details all packages on registry
request('/packages')
// Returns details of package 'some-mod-name' from user 'Soulweaver' with version '1.2.0'
request('/packages', {
author: 'Soulweaver',
package: 'some-mod-name',
version: '1.2.0' // If missing, just return latest
})
// Returns all packages by user 'Soulweaver' ordered by amount of 'likes' with 'desc'ending value
request('/packages', {
author: 'Soulweaver',
orderBy: 'likes',
sort: 'desc'
}) This could be extended to something like
|
Would it help if i can provide what all my site can track, as maybe some suggestions and possibilities? For example Category, Author, File Version, Link back to File, Download ID number, Review Rating, and some other things that may be useful. In fact if one of you all would like access to personally view these things in person on my site, I am willing to grant access to someone who knows that stuff. |
As registries gain more and more packages it may become challenging to scale without an API-specific search function. The Nexus has over 65k mods in a single category -- an API shim will not be able to return every single package, and even if so, effectively serve them at volume.
In instances where we're not relying on data from a GPM registry (for example, an API shim) we cannot rely on consistent metrics for categories, file versions, ID numbers, ratings, etc. I think these values should be optional or omitted entirely. |
According to our package format specification, a lot of these are covered by the package metadata:
So based on this, only So that would put registry sourced metadata to be at least:
These are probably metrics we shouldn't required, but could be optional for a registry to support. |
@zSoulweaver |
All looks good to me. I was just tossing information out there of what may be helpful on my end? Im really good with Papyrus, and python, and med at JSON, but what you all are doing i may as well wear my helmet and play with my crayons in the corner. lol. Ping me if there is anything i can do that would be beneficial to the project, i would love to help in any way. I use the same system as nexus, so if there is some information in the backend of the website stuff that i can provide, im willing. |
@Schaken yeah definitely, registry sourced metrics (like reviews or download count) that you mentioned are an important consideration. Not sure if you've seen the package format spec at WolvenKit/CP77Wiki#1, but that might give you some idea on what the required metadata we want for all packages is going to look like |
Yeah, that's correct. As examples by the |
Based on what you want, I am not sure how it could be compatible with a Invision based website like Schaken-Mods, there is not much freedom on APIs with Invision Community, you pretty much are only allowed to use the REST api after OAUTH authentication(with a key and the user account). Custom APIs would have to be implemented separately on a subdomain, totally separate from the website itself, it would have to have direct access to the Invision DB and file store, this all would be very difficult with how Invision stores and keeps track of files. |
We should specify what the package registry API should look like and how can websites implement a gpm-compatible interface for accessing the package registry.
Use this issue for related conversation and drafts
The text was updated successfully, but these errors were encountered: