Consider decoupling users from their gold. This means making a table called sometihng like user_gold that is a ledger of all gold changes for every user. You can then create a view which aggregates the ledger and groups by user to get every users gold.
Consider decoupling the is_adopted column from the user_create_connections table. Instead, you can have a table called users_adopted which can be a ledger with users and any creatures they've adopted. Any new adoptions get inserted into the ledger. Checking if a user has a creature adopted is then just a query into the users_adopted ledger.
Consider decoupling the creatures table from their attributes and then storing those attributes in a seperate table as a ledger that way you can see all the changes in a creatures attribute and what caused it. You can also create a view from which you can aggregate your ledger to get the attributes of any character.
Consider updating your users_treat_inventory to a ledger so you can get a history of any users inventory status.
carts_items can also be a ledger if you want
Carts
/carts/ - create cart endpoint
This endpoint does not have to require the user to pass in a username. Backend should be able to derive username from just the user_id. But username value doesn't seem to be necessary for your code regardless.
This endpoint is vulnerable to idempotency issues. Consider requiring the client to pass in a unique transaction id with each call and then check if that call has already been made before making any changes to data.
Every endpoint except this one that requires a user_id takes the user_id in the URL. This endpoint takes it in the text box. Consider making it take the user_id in the URL for your endpoints to be more consistent with one another.
/carts/{cart_id}/items/{item_sku} - set item quantity
Current implementation allows you to add items to a cart that has already been checked out. Consider making a completed_carts table and updating it with cart_id's that have been checked out.
This endpoint is vulnerable to idempotency issues. Consider requiring the client to pass in a unique transaction id with each call and then check if that call has already been made before making any changes to data.
/carts/{cart_id}/checkout/ -- checkout endpoint
Decouple users from their gold. Consider making a table called user_gold that is a ledger of all gold changes for every user.
Catalog
/catalog/ - get catalog endpoint
LGTM
Users
/users/create/ - create user endpoint
LGTM
/users/{user_id}/delete - delete user endpoint
I'm not sure you want to have this endpoint. It leaves the door open for a malicious user to iterate over id's and start deleting users. IF you do want to keep this functionality, then I'd suggest making your user id's in /users/create generate id's that are more unique and harder to guess.
This endpoint is vulnerable to idempotency issues. Consider requiring the client to pass in a unique transaction id with each call and then check if that call has already been made before making any changes to data.
/users/{user_id}/creatures/{creature_id}/play -- Play with creature
Tables
Consider decoupling users from their gold. This means making a table called sometihng like user_gold that is a ledger of all gold changes for every user. You can then create a view which aggregates the ledger and groups by user to get every users gold.
Consider decoupling the is_adopted column from the user_create_connections table. Instead, you can have a table called users_adopted which can be a ledger with users and any creatures they've adopted. Any new adoptions get inserted into the ledger. Checking if a user has a creature adopted is then just a query into the users_adopted ledger.
Consider decoupling the creatures table from their attributes and then storing those attributes in a seperate table as a ledger that way you can see all the changes in a creatures attribute and what caused it. You can also create a view from which you can aggregate your ledger to get the attributes of any character.
Consider updating your users_treat_inventory to a ledger so you can get a history of any users inventory status.
carts_items can also be a ledger if you want
Carts
/carts/ - create cart endpoint
This endpoint does not have to require the user to pass in a username. Backend should be able to derive username from just the user_id. But username value doesn't seem to be necessary for your code regardless.
This endpoint is vulnerable to idempotency issues. Consider requiring the client to pass in a unique transaction id with each call and then check if that call has already been made before making any changes to data.
Every endpoint except this one that requires a user_id takes the user_id in the URL. This endpoint takes it in the text box. Consider making it take the user_id in the URL for your endpoints to be more consistent with one another.
/carts/{cart_id}/items/{item_sku} - set item quantity
Current implementation allows you to add items to a cart that has already been checked out. Consider making a completed_carts table and updating it with cart_id's that have been checked out.
This endpoint is vulnerable to idempotency issues. Consider requiring the client to pass in a unique transaction id with each call and then check if that call has already been made before making any changes to data.
/carts/{cart_id}/checkout/ -- checkout endpoint
Catalog
/catalog/ - get catalog endpoint
Users
/users/create/ - create user endpoint
/users/{user_id}/delete - delete user endpoint
/users/creategenerate id's that are more unique and harder to guess./users/{user_id}/inventory/ - get inventory
Creatures
/users/{user_id}/creatures/ - get creatures
/users/{user_id}/creatures/{creature_id}/stats
/users/{user_id}/creatures/{creature_id}/feed/{treat_sku}
/users/{user_id}/creatures/{creature_id}/play -- Play with creature
/users/{user_id}/creatures/{creature_id}/adopt -- adopt creature