Routes Improvements

[idbentley]

Because of the complexity required to support continuous playback, please talk to me or a TA before you begin applying this feedback wholesale.

For the sake of this application, we need to be careful to differentiate between api (i.e. routes that are called with JavaScript) and normal Backend routes. Since most of your application will directly return and render html (as derived from pug templates) instead of returning JSON to be interpreted by a frontend framework (which we will see with React shortly), do not prepend the routes with /api and do not separate routes that render html from those that do work (like POSTs, PUTs and DELETEs).

This general feedback means that for example: you should move "/noisewave/login" into the Users table, it's method should be GET and it's description: "Renders Log In Form". Please apply this pattern to all frontend routes.

However, this project does require some api routes related to navigating while a playing songs in the background. These routes should still return html, that your JavaScript will use to update the view with innerHTML - they are not JSON endpoints.

Malformed Routes

• /api/songs/:songId/likes/:userId | DELETE This route can be simplified to: /likes/:likeId | DELETE.

Unnecessary Routes

• /api/songs/:id/likes | GET | Fetches the likes for a song Likes should be included on the Song object using sequelize include and the appropriate model associations. As such, this route is unnecessary.

• In general you have more comment routes than necessary, the GET /api/songs/:id/comments should be included through association and we can't see any reason why you would need to a single comment: i.e. GET /comments/:id.

• I think the same note applies to the GET /api/users/:id/songs/ - those songs can simply be included through association. It's not clear when you would need GET /api/songs for the main features of Soundcloud. If you wanted to make better use of this route, /songs could return a list of recommended songs for the current user, instead of all songs.

Final notes

Your search functionality is too vague. Please update your feature List document with the details of what types of search you would like to support, and add to your route specification the query parameters needed to handle those searches.