I am currently both a member of a software development team and a computer science teacher. As a teacher, I recently taught a lesson about REST API concepts in a web development class.
While preparing for my class, I realized that I had never really took the time to properly understand the difference between the POST and PUT methods in a REST API. In my defense, it has been a while since I have designed a REST API, as I have switched to using GraphQL over REST years ago. And I must admit that when, back in the day, I did have to implement REST APIs, I did not care enough about understanding the formal difference between PUT and POST and would just stick with POST for any endpoint that performed an update or an insertion.
Nevertheless, now that I had to teach people about REST, I had no choice but to figure out the missing bits in my understanding. And it turns out the difference between PUT and POST is quite simple to explain :
If your API route refers specifically to the entity it is updating or inserting (e.g. the route contains the entity’s ID), use PUT (as in "Put that right there!"). Otherwise, use POST. This is why PUT is more often used for updates, as updates require the ID of the entity to update, while the ID of an object is generally not known before insertion. Corollary : PUT is idempotent, and POST is not.
Anyways, I went and acquired that precious bit of knowledge, and then proceeded to teach it. The next day, I told my coworkers at my software development job about this anecdote. Now, I consider my coworkers to be above-average web developers – and yet, you guessed it, that conversation ended with me explaining the difference between PUT and POST in a REST API!
My coworkers are not even the only web developers with whom I had this conversation since teaching that class. There is another person, who is probably one of the best developers I know, who happened to not know exactly the difference between PUT and POST. And I am sure I could find many other developers in the same position.
Sure, all the aforementioned people happen to have been using GraphQL over REST for a while, so that might contribute to explaining this gap in their knowledge of REST concepts. But it cannot explain everything. First of all, because GraphQL has not been around for that long, so most of us have had to implement REST endpoints at some point in our past. Second, because a great deal of public API’s are still REST, so even developers who mostly use GraphQL still have to write calls to a REST API once in a while. Third and most importantly, because these developers were all AWARE of that gap in their knowledge.
This whole experience made me wonder : how many of these little gaps exist in our knowledge as otherwise competent programmers, that we are aware of, but do not fix? Furthermore, given that implementing an API that uses POST when it should really use PUT seems unlikely to cause any catastrophe, are we ignoring other blind spots while programming that might actually impact software projects negatively?
An example of a common programmers’ blind spot : the reason for binding methods in JavaScript
I can think of at least one such blind spot that I find common amongst JavaScript developers : that is knowing when you need to bind your methods, and when you don’t. And as with my story about the difference between PUT and POST, the answer to this question is actually pretty simple :
If you are going to pass your method around as a callback, and its body uses "this", then you need to bind it. Otherwise, you don’t. The reason is if you call "dog.bark()" directly, then the "bark" method knows that "this" refers to "dog". But if you pass "dog.bark" as a callback to something else, then you are really just passing a function that will not be treated as a method of "dog" when it is called. Binding "bark" to "dog" fixes that issue.
This is not that complicated to understand, right? And yet, how many JavaScript programmers decide not to take the time to understand this, and just end up binding all their methods in their constructors as it is the solution that "works" in all cases without further thinking? Well, it turns out this approach can impact performance negatively (or at least that was the case a few years ago when the linked article was published).
Acknowledging and fixing our blind spots
The bottomline of this is : some of our blind spots while developing software might be harmful and others might be harmless, but we cannot know for sure before we acknowledge them and take the necessary time – often just a few minutes – to fix the gaps in our knowledge. When driving, would you fail to check your blind spot before changing lanes even though you are perfectly aware that another vehicle might be in it? (If your answer is yes, please use public commute from now on).
My own experience has really convinced me that teaching a subject is a great way to perfect our knowledge of it. Now, I am obviously not suggesting that every software developer should also be a teacher – that would require an impractical student-to-teacher ratio – but coworkers constantly teach each other in the workplace, even if informally. Make it a thing. When you realize that a shared blind spot exists amongst your team, take it on yourself to teach your coworkers what they are missing – you will then have no choice but to really understand it yourself.
So, what blind spot can you think of that would be beneficial to check for your team or for yourself?