If you read my last article, you know that I just entered a new phase in my bootcamping journey at Green Fox (if you didn’t, you can read it here). I entered the project phase. What does this mean? That the students were divided into groups and are now working in a project together, in order to develop a software product.
I am in a back-end Spring project, developing a product that will help Green Fox manage its employees’ progression. Since Green Fox is a holacratic institution, the system is more complex than the traditional one: there are badges for different skills and each employee can claim new badges, that should then be approved (or rejected) by the peers.
Now, our daily routine is different from before. We are not given materials to learn; instead, we have stories to work on and we are supposed to find the materials ourselves and try to implement them in our project. The group also has the help of a mentor for about an hour each day — similar to a real working environment, as we have been told.
But, since the project is still in its early phase, today I would like to write about something we learnt at the end of the Orientation phase (the one just before the project) and that we will use heavily during this project: JSON format and RESTful APIs.
What is JSON?
JSON stands for JavaScript Object Notation and it is a completely language-independent text format that is mainly used to transmit data between a server and a browser.
It increased in popularity in the past years because it is very easy to read for humans and also easy to parse and generate for the computer, making it a simpler and more lightweight alternative to XML.
The structure of a JSON object is derived from JavaScript object notation syntax, meaning that data is organised in key/value pairs separated by commas, with the whole of the object being wrapped by curly braces and arrays being wrapped by square brackets, like so:
JSON objects are very useful to deliver data in REST APIs. Ok, but what is an API? And what is REST? Let’s see…
What is an API?
API stands for Application Programming Interface and, put simply, it is the messenger that takes requests and tells the system what the user wants to do, and then returns the response back to the user.
Let’s imagine that you are planning your next holiday and decided to book a flight. You can do it directly at the airline company’s website or you can do it through a third-party like Skyscanner or Google Flights, for example. If you chose the latter, how does this website know the information provided by the servers of the airline company? You guessed it, using an API.
But we mentioned a specific kind of API, one that uses the REST architecture.
What is a REST API?
A REST (REpresentational State Transfer) API allows the server to transfer to the client a representation of the state of the requested resource. It follows six constraints:
· Uniform Interface — this tells the RESTful service what to send to the client, in form of a document, image or other. Before a client can interact with a RESTful service, it needs to do two things: identify every resource the server has to offer and define a set of operations that can be performed in any resource with a predicable outcome.
· Client-Server — client and server should be separate, allowing each other to evolve individually. The server is called when the client sends a request, which the server reacts to by sending a response. But, if there is no call of the server by the client, no interaction happens.
· Stateless — every interaction between client and server is stateless, there are no sessions and no history.
· Cacheable — since a stateless API can be forced to handle a large number of requests, it should allow the storage of cacheable data. If a message is cacheable, the client doesn’t need to repeat the same request, which contributes to a better performance of the system.
· Layered System — this constraint builds in the client-server separation mentioned above and allows the overall architecture of the service to be separated by individual layers that work independently and only interact with the layers immediately adjacent to them. This also benefits the security of the system.
· Code on demand — this is the least known of the constraints and, in fact, it is optional when defining a REST API. Basically, instead of returning an XML or JSON object, it allows for the server to return executable code.
I hope these notions are now clear to you! In the upcoming weeks, we will continue with the project and the next big step is to implement OAuth2 authorisation. I might read an article about it, so stay tuned!
Diana Bernardo 