API Routes for website and local registry/fpm

[henilp105]

I have considered the following API Routes for backend so that they can be directly used by the website and the local registry/fpm :

1. /packages/?query=<name or tag or description keywords> This endpoint would send a GET request to API backend to fetch all the packages with name in package name, tag in package, keywords in description of package and return them in a json format.

2. /packages/<package_name> This endpoint would send a GET request to API backend to fetch the package tarball from aws s3 object and to return the tarball of package.

3. /auth/login This endpoint would send a GET/POST request to API backend to verify if the user exists and has exactly same password and email if yes, updates the loginAt field in users collection, generates a unique uuid sets it users collection and returns a uuid as a cookie.
   

4. /auth/logout This endpoint would send a GET/POST request to API backend to logout if the user exists and has exactly same uuid if yes, updates the logoutAt field in users collection, removes uuid users collection and resets cookie with uuid and returns json.
   

5. /auth/signup This endpoint would send a GET/POST request to API backend to verify if the user exists and has exactly same email if yes, shows errors else , creates a new user in users collection with the details,and adds the loginAt field in users collection, generates a unique uuid sets it users collection and returns a uuid as a cookie.

6. /users/<username>/ This endpoint would send a GET request to API backend to verify by uuid and then to return all the packages uploaded by the user and their maintainer in json and also return is_admin, is_maintainer ( for the web interface, just to show the options in the menu to navigate to another API to edit packages/users which would be authenticated. ) . if user is admin then he would be shown options to search/show all the users to delete them and to add a new user with different levels to access and to search/edit/delete the packages, make an new user a maintainer. if the user is maintainer then he would be add/edit/delete different versions of the packages he would be maintaining.

7. /packages This endpoint would send a POST request to API backend to verify by uuid and then to add a new package or a version to the collection and then also request the maintainer to join as a maintainer if approved on maintainer side , returns a json with status code.

8. /packages/package-id This endpoint would send a PUT request to API backend to verify by uuid and then to update a package details to collection and then also request the maintainer to approve, returns a json with status code.

9. /users/<username>/<package_id>/delete This endpoint would send a GET/POST request to API backend to verify by uuid and then to delete a package from collection and returns a json with status code.

10. /users/<username>/maintainer/ This endpoint would send a GET/POST request to API backend to only for web interface and shows the loggedin user the requests from a different packages with author names if the user approves them he would be added as a maintainer for that package, returns a json with status code.

11. /auth/forgot-password/ This endpoint would send a GET/POST request to API backend to only for web interface and checks if an email exists if it exists then it would send the reset link with a new generated uuid by mail to user, returns a json with status code.

12. /auth/reset-password/<uuid> This endpoint would send a GET/POST request to API backend to only for web interface and checks if uuid exists if it exists then it would ask to enter a new password and change in the users collection and remove the uuid and resets cookie with uuid , returns a json with status code.

if the user is admin them direct access would be granted to delete/update/upload any package/user. I would like to request all the Community members to review and add suggestions on this format of APIs. Please feel free to add here if I have missed any other important aspect.

Thanks and Regards, Henil

CC @awvwgk @fortran-lang/admins @fortran-lang/fpm

[henilp105]

CC @minhqdao Please refer suggested API Routes for the terminal and fpm CLI.

[minhqdao]

I can envisage a couple of scenarios for resolving a dependency:

1. User enters package name and just wants to get the newest version of that package. (e.g. /packages/datetime?)
2. User enters package name with specified version. (/packages/datetime?version=1.0.0?)
3. User enters package with version range/constraint and the backend has to find out if a version can be matched. (/packages/datetime?min=1.0.0&max=2.0.0?)

In all cases, a JSON of the relevant document (package) is returned if the version could be resolved. Otherwise return error message ("Package not found.", "Version doesn't exist." etc.).

[henilp105]

@minhqdao for resolving a dependency on your side , this are the APIs that you could use :

1. To search a package we would have to use /search/<name or tag or description keywords> API then API would return all the versions of that package and also the related packages in a json format with only required information to download a new package/tarball . ( priority would be given to latest tag ).
2. Only the version filtering and matching would be done on frontend/fpm terminal side.
3. I have also added in the above description that it would be returning the appropriate responses based on query.