DD #2 Sample State & Backend Routes

Nice job the on the sample state and backend routes, Mark! Here's my feedback --> checkmarks next to should do's, suggestions are just bullet points.

SAMPLE STATE

[x] companies: not sure what the data would look like (depends on the API), but you'll want some property pointing to the historical prices of a company's stock so that you are able to graph it. that would probably involve some nesting, as each historical data point would have a date / price. nesting here is fine since there is no duplicate info and it's specific to that resource (not related to another resource in your app).

BACKEND ROUTES

users:
- [x] in terms of resources from the backend, what exactly is returned by api/users/:id? almost certainly their shares, maybe also their watchlists? think also about whether this would make other routes moot (e.g. if the only time you need all of a user's shares is for their show page, might not need a shares index nested under users)
[x] stocks: I would use consistent naming conventions; either use companies or stocks and stick with it
shares:
- [x] you might want to think about the POST & PATCH shares routes; sometimes you might buy shares after already owning shares in a company, which might make it a patch
- [x] PATCH and DELETE routes do not need to be nested; you have the share id so you can retrieve the share from the wildcard, and from there you can get its owner.
- likewise, your GET and POST routes might not need to be nested under users, since you could just use the current user's id. consider if you would want the POST route to be nested under companies/stocks (would simplify the ajax request)
[x] watchlists: likewise, no need to have nested routes for PATCH or DELETE or GET /api/users/:id/watchlists/:id

mcamilleri10 / Blackbird