You can see a functional version of the application you should build here.
Here’s an Entity Relationship Diagram of the database, for reference. Also remember to refer to the comments at the top of the model files:
Unless otherwise noted, if multiple rows are being displayed, they should be ordered by the created_at column (ascending).
/cuisines
should show a list all cuisines.
/dishes
should show a list all dishes.
For example:
/dishes/26
should show the details of one dish.
/neighborhoods
should show a list of all neighborhoods.
/venues
should show a list of all venues.
For example:
/venues/27
should show the details of one venue.
/users
should show a list all users.
For example:
/users/4
should show the details of one user.
For example:
/add_bookmark?input_user_id=1&input_dish_id=2&input_venue_id=3
should add a record to the bookmarks table.
Be sure to name the keys in the query string exactly input_user_id, input_dish_id, and input_venue_id.
For example:
/users/4/bookmarks
should show a list of the bookmarks that belong to the user with ID 4.
For example:
/dishes/5/bookmarks
should show a list of the bookmarks that belong to the dish with ID 5.
For example:
/venues/6/bookmarks
should show a list of the bookmarks that belong to the venue with ID 6.
For example:
/remove_bookmark/32
should delete a record from the bookmarks table.
For example:
/users/4/bookmarked_dishes
should show a list of the user’s bookmarked dishes.
For example:
/dishes/5/experts
should show a list of the venues that have been bookmarked for the dish.
For example:
/venues/6/specialties
should show a list of the dishes that have been bookmarked at a venue.
For example:
/venues/6/fans
should show a list of the users that have bookmarked any dish at the venue.
If a query string is present on the end of /dishes with a cuisine ID, use it to filter the list of dishes.
For example, if I know that “Breakfast” has the ID of 2 in the cuisines table, then:
/dishes?cuisine_id=2
should show only Breakfast dishes.
Be careful not to break plain old /dishes (without a query string on the end)! Requests both with and without a query string should be handled gracefully.
There are many different tools that you can use to achieve this.
If a query string is present on the end of /venues with a neighborhood ID, use it to filter the list of venues.
For example, if I know that “Hyde Park” has the ID of 10 in the neighborhoods table, then:
/venues?neighborhood_id=10
should show only the venues in Hyde Park.
If a query string is present on the end of /users/[ANY EXISTING USER ID]/bookmarks with a dish ID, use it to filter the list of bookmarks.
For example, if I know that “Biscuits and Gravy” has the ID of 26 in the dishes table, then:
/users/4/bookmarks?dish_id=26
should show only the bookmarks that belong to the user with ID 4 that are for Biscuits and Gravy.
I found it helpful to define the following association query shortcuts for myself in my models before I started to build out my API; but you are not required to.
User#bookmarksUser#bookmarked_dishesUser#bookmarked_venuesUser#bookmarked_neighborhoodsVenue#neighborhoodVenue#bookmarksVenue#specialtiesVenue#fansNeighborhood#venuesDish#bookmarksDish#cuisineDish#expertsDish#fansCuisine#dishesCuisine#expertsBookmark#dishBookmark#venueBookmark#userFor me, it’s worth the up-front investment to write these instance methods and have them at my fingertips for the rest of the time I spend working on the application, because most association-related queries are re-used many times.
Remember that you can use .distinct on a collection to remove duplicate records.