Georgiana Gligor

Ward Cunningham introduced this metaphor, explaining that “shipping code first time code is like going into debt”, and immediately emphasizing that not repaying it very soon “counts as interest on that debt”. The metaphor used here is very powerful, because we can immediately visualise the added interest to the initial debt. The same author remarks, more than 20 years later, that: “The irony of our industry is that code turns out to be ‘harder’ than hardware when it is thought to be finished and the developers dismissed.”

Bertrand Meyer was the one who introduced the [distinction between Command and Query terms, when he stated that any method should be either a Query (simply reads information) or a Command (performs an action), but not both.

This article is part 2 of a series showing how to prepare, design, and implement a RESTful API. After setting up the grounds in the first part, this time we are going to look at how an API is designed, what concerns we should have in mind when doing that. But first, we will have a look at what REST is, and what are the architectural constraints it imposes on a system.

Developing applications professionally on the LAMP stack imposes use of modern frameworks. They standardize the way we work by using a predictable code and file organization, come prepackaged with basic utilities and libraries. Moreover, frameworks address security concerns at the core of the software, are a key factor in teamwork by enforcing code standards and easier onboarding of teammates. Last but not least, they are backed by fantastic communities, and make us more efficient by helping focus on the functionality of our project.