Mar 27 Tue - API Endpoints¶
Owen, Sean, and Richie
Small meeting to talk about the functions
Richie brings up the design phase document to show the diagram.
Richie wants a function for each endpoint. For example, there will be an endpoint called /users and it will contain key-value pairs where the key is a user ID and the values are data about the user. There may be 2 functions for /books so that they can be accessed by ID or keywords.
Endpoints:
Think of the endpoints as their own classes.
Here’s a representation of a possible database. There may be some bits missing, for example, a book has more information than just title, author, and ID.
- /users
- $user_id
- name
- list of listing IDs for listings created by this user
- /books
- $book_id, perhaps ISBN
- title
- author
- list of listing IDs for listings for this book
- $listing_id for each listing
- /listings
- $listing_id <– this is one particular listing
- price
- condition
- book_id
- user_id
- status
Frontend will send a request with either a query or some number of book IDs. When they send a query, backend needs to do some kind of search. When they send book IDs, just look up those books.
Things that frontend needs from the API:
In any of the “get” actions above, provide all information about the object being requested.