# 425 REStful planning review

* One `member` can have many `books`. `Members`:`Books` have a **1:M** relationship. This relationship describes books being checked out of the library. It is possible for a `book` to not have a `member`, if it is not checked out.
* One `book` can have many `genres`, and a `genre` can have many `books`. `Books`:`Genres` have a **N:M** relationship.
* The table `books_genres` is simply a join table, used to to maintain a **N:M** relationship. It shouldn't be a part of any **URL**.

Your Task is to write a `RESTful` routing chart for the library system's API. Your API will need to serve full CRUD on `members`, `books`, and `genres`. Do not worry about authentication, another team is handling that.

members:

* [x] see the information about a member -- books checked out -- money owed, member id
* [x] let a member join the library
* [x] remove a member from the library
* [ ] update some information about a member (such as paying back library fees)

* [x] search for a member -- index of all members

You can use this markdown chart:

| HTTP METHOD (_Verb_) | URL (_Nouns_) | CRUD | Response | Notes |
| -------------------- | ----------------------------------- | ------- | -------------------------------------- | -------------------- |
| members controller | | | | |
| GET | /members | READ | array of members `[ member, member ]` | |
| GET | /members/:member_id | READ | a member `{ member }` | |
| POST | /members | CREATE | redirect to `GET /members/:member_id` | |
| DELETE | /members/:member_id | DESTROY | status `204` | |
| PUT/PATCH | /members/:member_id | UPDATE | redirect to `GET /members/:member_id` | |
| books controller | | | | |
| GET | /books | READ | array of books | |
| GET | /books/:book_id | READ | a book | |
| POST | /books | CREATE | a new book | |
| PUT | /books/:book_id | UPDATE | update the deets of a book | |
| DELETE | /books/:book_id | DESTROY | remove a book | |
| 1:M members:books | | | | |
| PATCH | /members/:member_id/books/:book_id | | | checks in/out a book |
| M:M members books | | | | |
| POST | /members/:members_id/books/:book_id | | | checks out a book |
| DELETE | /members/:members_id/books/:book_id | | | checks in a book |
| genres controller | | | | |
| POST | /genres | CREATE | | |
| POST | /books/:book_id/genre/:genre_id | CREATE | status `204` | |
| DELETE | /books/:book_id/genre/:genre_id | DESTROY | status `204` | |
| | | | | |

??

#### Things to keep in mind

* A `book` can exist in the database without a member creating it, unlike our blog example. How will this affect the API's endpoints (_URLs_)?
* You will need to create routes that allow `members` to checkout `books` and return `books` to the library. What HTTP methods should you use for these? What _URLs_ would best describe that models that are having actions taken on them _and_ the relationships between the data.
* **HINT:** if your _URLs_ have the word `checkout` in them, you are falling victim to one of the dreaded **_anti-patterns_**!
* `books` and `genres` are **N:M** and we have the following user stories. Think of the `HTTP methods` first and then think about the _URLs_. How can you best describe the data relationships in your _URLs_:
* as a user, I would like to see all the genres a particular book is in.
* as a user, I would like to see all the books a particular genre has is in it.
* You will need need routes to handle adding a book to a genre and vice-versa

| HTTP METHOD | URL | Query Strings | CRUD | Response |
| ----------- | ----------------------------- | ------------- | ------- | --------------------------------------------------------------- |
| Pages | | | | |
| GET | / | | READ | render home page |
| GET | /additional_resources | | READ | render page with recommendations for study materials |
| GET | /unsubscribe | | READ | render page to request an unsubscription link |
| Questions | | | | |
| GET | /questions/:questionId | | READ | render question with id of :questionId |
| GET | /questions/:questionId/image | | READ | serve image associated with :questionId |
| Study | | | | |
| GET | /study | | READ | render page with all study areas and domains |
| GET | /study/:domain | | READ | render domain of study and all topics |
| GET | /study/:domain/:topic | | READ | render topic to study |
| Users | | | | |
| GET | /:userId/unsubscribe | | READ | render page to confirm unsubscription |
| DELETE | /:userId/unsubscribe | | DESTROY | deletes user and their info |
| POST | /subscribe | | CREATE | create user in db |
| GET | /:userId/subscription_success | | READ | render template welcoming user -- dispatch most recent question |