-
Notifications
You must be signed in to change notification settings - Fork 1
API Design
For this project, we're designing a RESTful API to allow easy communication between clients and the server, while also decoupling the parts of the application.
As far as paths go, we should strive for a somewhat universal archetype. Below are my recommendations for how to structure things.
/deku/api/users -> Should return a list of all users (possibly truncated?)
/deku/api/users/<int:id> -> Should return a user based on their unique id
/deku/api/cards -> Should return a list of cards (should be truncated, maybe 20 or so)
/deku/api/cards/<int:id> -> Should return a card based on its unique id
/deku/api/users -> Should create a new user
/deku/api/cards -> Add a new card to the database
/deku/api/users/<int:id> -> Update specific user with info passed
/deku/api/users/<int:id> -> Delete a user from the system
/deku/api/cards/<int:id> -> Delete a card from the system
This is just a start. More methods will certainly be necessary as we flesh out the application. It is also worth noting that some methods shouldn't be openly available. Some of this will be handled by permissions, others by the interface. Some should simply not be allowed outside of the interface. For example, you should not be able to create cards using curl. Or delete users. That's stupid.
Use your best judgment, and happy coding.