In my previous entries, I have been taking topics (such as REST APIs, coding smells, and so on) and merely providing general applications of the subject. This is not to say that the posts are simply summaries; rather, they provide a little bit of coverage on a lot of ideas within the subject. This time, I’m going to something a little different – I want to cover a specific issue involving REST API calls. This issue involves the return messages from the calls, specifically the “200” success message vs. the “404” failure message.
To summarize, a “200” return message is essentially an “OK” message. It means that, when trying to access data, that data can be found to some degree (even if its value is zero). For example, even when trying to access an empty list, it will return a “200” despite having no items within the list. In contrast, a “404” error is commonplace on the internet, to the point where even those who aren’t tech-savvy at least understand the general idea – it means that requested data cannot be found. in short, it doesn’t exist (at least not to the server).
A good way of discerning the difference between these two is to take a shelf of soup cans. If we have an empty shelf, then we will get a “200” message – the shelf exists, but there are no soup cans on it. Meanwhile, a “404” would mean that we cannot get any soup because the shelf does NOT exist.
The blog associated with this reading is short, sweet and to-the-point; it briefly explains the “200” and “404” messages, alongside some other return messages (and even some images of cats!) I chose this reading due to its brief, yet informative nature – these topics are not difficult, and don’t require too much explaining. The cats also make for a humorous touch, allowing the learning process to be more “fun” and “easy going”.
While a smaller detail, this distinction between “zero” and “null” is not to be taken lightly. I plan on using this knowledge in future practice, as it will reinforce good coding practices; it is not enough to say “we have no soup” and be done with the problem. We need to know exactly WHY we don’t have any soup, otherwise this faulty coding can lead to smells and other issues down the road. It is always important to not only understand what the result of a program is, but also how it gets that result. We also need to ask ourselves if this result is obtained “properly” – meaning that it is done in a way that works smoothly with the res of the program.
Link: https://blog.short.io/status-codes/
From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.
