As I continue to write more and more on APIs (specifically RESTful APIs), I realize I use more concepts in these posts that I don’t explain. In an effort to demystify some of these concepts, I’d like to get into some of the requests I use when using services like external API’s. For the examples of each request, we’ll use the fake url of “http://localhost/roster”, where this is a typical roster of names.
This is one of the most commonly used requests is the ‘get’ request. In short, the ‘get’ request is used to retrieve data from the external source. It should be noted that this request is the default request when implementing something like a fetch request. Sending a ‘get’ request to “http://localhost/roster” would return a full roster list of all created entries.
‘Post’ requests are the beginning of where things get complex. For starters, unlike the ‘get’ request, this will actually change the database, as using a ‘post’ request is used to create a new record in the backend. Sending a ‘post’ request to “http://localhost/roster” would create a new entry in the roster listed from the ‘get’ request.
‘Put’ requests are how someone may edit existing entries within the database. Much like the ‘post’ request above, as well as the next request, this will change the data in the backend as well. In these cases, we need to identify which entry needs to be changed. When making these requests, keep that in mind. Using our url from before, it looks just a little different, like using an id number. Using “http://localhost/roster/4”, for example, will ensure that only the record with id of 4 will be updated, as opposed to changing our entire database.
As you can guess from the pattern shown in the above requests, we’ve covered reading, writing new, and updating records in our data. Lastly, we’ll cover the ‘delete’ request. Just like the ‘put’ requests, this needs (be very careful here) to reference a specific entry. Similar to above, using the “http://localhost/roster/4” url for this request, it will remove all data tied to the id of 4 from our backend. This can be dangerous, as once this code triggers, there is no confirmation that a common computer user may be used to, so be careful when using and testing these requests (I myself use dummy data when testing any requests that change my backend).