Microsoft Word – Document5
Learning Outcome
By the end of this exercise, you will further develop your skills
in building APIs, and building on your understanding of REST.
Prerequisites
You will be building on what you had from Exercise 5,
continuing to use Sequelize to programmatically interact with
your database.
If you haven’t done Exercise 5, please see the prerequisites
from that exercise.
Getting Started
You will be building on top of what you had from Exercise 5.
Just like in Exercise 5, you’ll need to install the Sequelize
package. You can find that information on the Getting Started
section of Exercise 5.
Task
In your previous assignment, you updated your GET requests
to interact with your database via Sequelize, but you didn’t
update the POSTs. We’ll expand on this to get your Music App
to be fully operational again, except we’ll be changing the APIs
up and adding a few new ones.
In Exercise 3 when you built your POST /api/playlists API,
it took care of any “Update” in your application (adding a new
playlist, or adding songs to a playlist). That was not a very good
way of building APIs (remember, I’m teaching you the bad
ways of doing things and so you understand why the good
ways are good!). It wasn’t good because:
They send far too much data for every change (why send
all the playlist data when you could just send which song
you’re adding to which playlist?).
They are not RESTful.
With the following tasks, we’ll make our API requests more
efficient, more RESTful, and functional using the ORM.
Adding Songs to Playlists
In exercise 3, you persisted playlist data to disk by sending all
of the Playlist data via a POST to /api/playlists. Instead we
will create a APIs specifically for adding songs to playlists.
The following two API requests described both solve this in a
better way. You can implement *either one* (both described
just to help with your understanding of PUT vs POST).
PUT /API/PLAYLISTS/:ID
PUT is used when you want to update an existing resource. But
when using a PUT, you should also be providing all the
information necessary, because it will replace the entire
resource. Remember – PUTs should be idempotent, meaning if
you keep issuing a PUT request repeatedly, only the first
request should actually change any state in your database.
The body of the PUT request should be the _entire_ list of songs
(not just the one being added). For example, if you were adding
song 64 to a playlist with songs 8, 16, and 32, your request
would look like this:
PUT /api/playlists/4
{
name: “Some Awesome Playlist”,
songs: [8, 16, 32, 64]
}
The result is that your Playlist #4 should contain songs 8, 16,
32 and 64. Don’t worry about dealing with invalid POST body
data for this exercise. The response should be a 200.
On the server you’d either delete all of the songs in the playlist
and then add the new ones, or you’d do a diff to see what
changed and perform the necessary operations to add/remove
based on that diff. How you implement this is up to you.
But this is also not very efficient in our case, because we’re not
doing any bulk operations (it could be useful if your UI didn’t
persist songs until you press “Save” though!).
So here is another API that fits our use case a bit better:
POST /API/PLAYLISTS/:ID
But you might say “Wait, I thought we should only use POST for
create?”. While it’s true that POST is the only HTTP method you
should use when creating a resource, it doesn’t mean you can’t
use it for updates. It’s also used when you want to make an
update that is non-idempotent, which we are doing in this case
(as doing the following POST would update the state of the
server by continuously adding this song over and over).
An example request to add song 64 to a playlist with 8, 16, and
32 would look like:
POST /api/playlists/4
{
song: 64
}
This should add song 64 to playlist 4. Don’t worry about
dealing with invalid POST body data for this exercise. The
response should be a 200.
UPDATING APP LOGIC
You should also update your Music App JS logic to call one of
these two methods (instead of using POST /api/playlists
which was the case from Exercise 3). Which one you choose is
up to you, and no it doesn’t matter for your marks.
Creating new Playlists
In exercise 3, you persisted new Playlists through the same API
as adding songs (POST /api/playlists). We’ll keep
/api/playlists, but this time it’ll strictly be used to create
new playlists.
POST /API/PLAYLISTS
When creating a new playlist, it should accept a “name”
parameter in the body like so:
POST /api/playlists
{
“name”: “Second greatest playlist”
}
Don’t worry about handling invalid POST body data in the
request. The response should contain a 200, and the id and
name of the new playlist:
{
id: 101
name: “Send greatest playlist”
}
UPDATE. It’s also fine if the response contains a JSON response
containing an empty array of songs:
{
id: 101
name: “Send greatest playlist”,
songs: []
}
UPDATING APP LOGIC
When you get a response back from the server, add the new
playlist to your MUSIC_DATA in-memory state object, and
update your UI with the new playlist.
(interesting tidbit: you could add it to the UI right away, doing
so would mean building a Optimistic UI]), but you also have to
deal with what happens if the server actually ends up rejecting
your request).
Removing a song from a playlist
DELETE /API/PLAYLISTS/:ID/
The body of the DELETE request should contain the song id
that you want to remove from a particular playlist. For
example:
DELETE /api/playlists/:id
{
song: 64
}
Generally DELETE requests should be idempotent, but since
our application state doesn’t know about the ids of the
relationships (and I don’t think it should), we’ll make an
exception here (REST is not a perfect science ????).
UPDATING APP LOGIC
This is new functionality you’ll add to your UI – you’ll be adding
a “Remove” button on the songs listed when looking at the
songs in the playlist. In your UI for that page, add an “x” button
to the right of the “+” button (use the same x you used in the
modal dismissal).
When clicking the “x”, the song should be a) removed from
memory, b) removed in the UI, and c) remove from the DB via a
call to your DELETE API.
Requirements
*One* of PUT /api/playlists/:id or POST
/api/playlists/:id, which updates the Playlist at id
with the contents of the request body. (2 mark)
“Add songs to playlist” in your UI uses one of the above
API calls. (1 mark)
POST /api/playlists creates playlists and returns the
playlist id. (2 marks)
“Create Playlist” in your UI uses your updated POST
/api/playlists. (1 mark)
DELETE /api/playlists/:id deletes the song from
playlist id specified in the body. (2 marks)
Add “Delete song from playlist” functionality in UI. (1
mark)
“Delete song from playlist” in your UI uses your DELETE
API to persist changes. (1 mark)