Schema/API Design Comments- Ella Hagen

[elhagen13]

1. For style in your api spec, you say it should be constrained to options such as "high tops, low, mid, etc," but right now a user could type in anything, so it might help to add an enum to the database so they'll be forced to choose.
2. Similarly, I think some other fields like color could be changed to an enum, just so it's more restrictive.
3. It could be good to implement a function that gets all listings for a specific store or add a store field to the search function so if a customer has a specific store that they know and trust, they can look to see what the store offers.
4. For simplicity's sake, this might be unnecessary, but to fit your design, there are a couple fields whose data types could change. The main one being size could be a float instead, so that way people can sell shoes that are, for example, size eight and a half.
5. For store verification, it might be good to implement the ratings/review system, so that way only stores that have good reviews and ratings can be verified, regardless of how many shoes they have sold.
6. Maybe you could add a "condition" parameter to the listing so customers could know whether the shoe is used, new, lightly worn, or etc.
7. I think this is just a matter of preference, but the endpoint paths could contain more information about the transaction taking place. For example, in the set quantity function, instead of "set_item_quantity", it could be "/{cart_id}/listing/{listing_id}."
8. I would consider maybe automating the verification of stores, so maybe after a customer has purchased a shoe/left a rating, it would check to see if it meets the qualifications for verification. That way the administrators wouldn't have to do it by hand.
9. In the search function, in the array of listings, it might be nice to add whether or not the store that is selling it is verified or not.
10. This is just a suggestion, but the functions could be broken up into different files, perhaps the search function could go into it's own file, since I'm not sure if it really matches the purpose of the other functions in carts.py.
11. Similarly to the one above, I think the filter endpoint should probably be something like "/filter" instead of "/carts/filter" since it doesn't really have anything to do with carts.
12. Perhaps consider having it so the filter endpoint doesn't need the API key since it's a function that doesn't really need proper authorization and should be available for all customers to access.