https://github.com/tca166/cdp
A demo game store API
https://github.com/tca166/cdp
Last synced: over 1 year ago
JSON representation
A demo game store API
- Host: GitHub
- URL: https://github.com/tca166/cdp
- Owner: TCA166
- Created: 2023-04-20T11:30:53.000Z (over 3 years ago)
- Default Branch: master
- Last Pushed: 2023-05-10T16:59:27.000Z (about 3 years ago)
- Last Synced: 2025-02-07T16:43:33.708Z (over 1 year ago)
- Language: Java
- Homepage:
- Size: 12.4 MB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Game Store API
A demo backend API for an online game store.
## API Endpoints
1. GET /games
Returns all games in the database in the JSON format.
Arguments:
- name:str
A string that each result's name must contain
- studio:str
A string that each result's studio must contain
- date:str(10)
A string that each result's release date must contain
2. POST /games
Returns all owned games by the user associated with the provided key.
Arguments:
- key:str
Key used for authentication
3. POST /games/delete
Deletes a game entry from the database with the provided uid.
Arguments:
- key:str (with admin privileges)
- uid:int
Id of game to be deleted
4. POST /games/add
Adds a new game entry to the database with the attributes in arguments.
Arguments:
- key:str (with admin privileges)
- name:str
- date:str
- studio:str
5. POST /games/update
Updates a single game entry attribute.
- key:str (with admin privileges)
- uid:int
- attr:str
Attribute key to be updated.
- val:str
Value to update the attribute with.
6. POST /key/valid
Returns if the key in POST arguments is valid.
Arguments:
- key:str
7. POST /key/valid/admin
Returns if the key in POST arguments is valid and admin capable.
8. POST /key/register
Registers the user and makes him eligible to receive keys.
Arguments:
- login:str
A user login that will be later used for verification during key issuing.
- pass:str
A user password used in tandem with login.
9. POST /key/get
Issues a new key for the user, with a permission level fitting their user permission level.
Arguments:
- login:str
- pass:str
- expiry:str
Either "auto" meaning tomorrow, a date formatted in "YYYY-MM-DD" or not provided (null) meaning never.
Perpetual keys may only be issued by admins.
## Authentication
Authentication is not necessary for all GET endpoints, and is provided in POST requests via the use of a key attribute in all requests.
The exception to that are the /key/register and /key/get endpoints that are used in key issue process.
This system ensures the backend can verify user identity without exposing any of their credentials, while also allowing access to automated clients and having two levels of authority over served content.
What's more this system has a built in key expiry that may only be turned off for keys generated by admins.
A frontend client can easily initialize secure data exchange by obtaining a one day valid key via the get endpoint and then use that key in all endpoints requiring authentication.
### Example interaction flow
1. Client registers to be eligible to receive authentication keys using POST /key/register
2. Client requests a new key using POST /key/get
3. Client verifies the capabilities of the key using POST /key/verify and POST /key/verify/admin
4. Client uses the key to authenticate himself and perform actions like POST /games
5. After a set amount of time the key expires, and needs to reissued.
Extremely high quality diagram of the above:
### Permanent keys and admin users
Admin users are indicated in the database by a single field, and keys issued to them are marked accordingly.
These users cannot be registered using the API, and need to be manually created.
Keys issued to admin users hold admin privileges, and grant access to admin endpoints.
Also admins may request keys that don't expire, for automated clients.
## Database
Due to it's relative simplicity and my experience with it I chose sqlite as the engine to power the database.
It removes a lot of the unnecessary data types from SQL while keeping all the necessary features.
## Example commands for testing
```Bash
curl -X GET localhost:8080/games
#outputs json contents of table games
curl -d "key=4shrg654ccI=" -X POST localhost:8080/key/valid
#true
curl -d "key=4shrg654ccI=" -X POST localhost:8080/key/valid/admin
#false
curl -d "key=test" -X POST localhost:8080/key/valid/admin
#true
curl -d "key=4shrg654ccI=" -X POST localhost:8080/games
#[{"date":"1993-12-10","studio":"ID","name":"Doom"}]
curl -d "login=test&pass=1234&expiry=auto" -X POST localhost:8080/key/get
#json with key and expiry
```
## Notes
- I had trouble with Java setup, thus two jar files are bundled.
- The games table has very little columns, but that's not important and can be easily changed.
- This was ultimetely rejected. It was noted however that I could have improved this project using a REST approach(guess using the Quarkus rest client wasn't RESTful enough) and I shouldn't have developed my own authorisation system and used a premade one