REST (Representational state transfer) is arguably the most popular architectural style for designing HTTP-based web APIs these days. While the basic idea is easy to understand, there’s a lot of corner cases that are not so straightforward. This has been on my mind lately while trying to revise the conventions for VocaDB’s REST API. It turns out that finding answers to some of these questions is difficult, and finding concrete examples of “proper” REST APIs that follow the conventions as precisely as possible is even more difficult. I decided to write something about the issues I’ve faced.
I had the following problem: let’s say I have a class called “Song”. I want to load it from the database and transform it to a data transfer object class called “SongDto” which includes only a subset of the original Song class’s properties.
Majority of programmers with some sense of pride would tell you they write the best possible code with uncompromising quality. Of course this isn’t true, and most of the time not even realistic. Unless you’re building software for a NASA space probe, aiming for ~90% perfect is probably the most cost effective.
My colleagues might consider me demanding (read: asshole) because I often criticize their code, but I’m not a compulsive perfectionist and I do settle for less than perfect solutions when it’s justified.
I’m not religious about it, but I think that having good set of automated tests is one of the best ways of ensuring high quality of the software. Still, often I see otherwise competent developers saying things like
- “You’re not going to catch the errors anyway so it’s just unnecessary work”
- “My code is so simple and easy to understand, it doesn’t need any tests”
- “Having unit tests is just extra maintenance because the tests will fail anyway when code is changed”
I know there’s tons of articles about automated testing already, but I wanted to write my opinion, perhaps just out of frustration of having to deal with such people.