The latest in-class activity from CS-343 introduced me to Representational State Transfer (REST), which is an architecture used by Client-Server APIs. The activity was helpful in explaining standard HTTP methods which are used by REST, specifically GET, PUT, POST, and DELETE, but it didn’t really focus on explaining what REST actually is and how APIs that use it are structured. For this reason, I decided to further look into the fundamentals of REST and how to use it. While researching, I came across a blog post by Bivás Biswas titled “How not to blow your REST interview.” The post can be found here:
While this blog does indeed give interview tips, it also helps explain REST and the design principles it follows. Biswas focuses on five main principles of REST that RESTful APIs follow, which include the contract first approach, statelessness, the client-server model, caching, and layered architecture. I chose to share this blog post because its organization of its information on REST helped make it easy to follow and understand. For this reason, I think the blog is an excellent resource for learning about REST, and I could see myself coming back to it as a reference if I work with REST in the future.
I liked that Biswas opened the blog by acknowledging common misconceptions about RESTful APIs that he has heard in interviews. One of these misconceptions was that RESTful APIs simply follow the HTTP protocol, which is a misconception I may have developed myself due to the aforementioned class activity being focused on HTTP. The fact that this was immediately stated as incorrect helped indicate to me that REST was more detailed and complex than I understood from class.
I also thought that Biswas’ approach to explaining the five principles of REST was particularly effective. He makes use of analogies and examples to demonstrate each concept instead of relying on technical terms that newcomers to the topic, such as myself, would likely not understand. For example, he explains the contract first approach with a mailbox analogy by suggesting that applications can get the same data without changing URIs in the same way that people can get their mail without changing mailboxes. Similarly, layered architecture is explained by comparing an API’s Gateway layer to a bed’s mattress. Much like a bed frame can be changed without affecting how the mattress feels, changing the fundamental layers of a RESTful API does not change how applications interact with the API’s Gateway. Analogies and examples always help make complex concepts easier to understand for me, and their use in this blog greatly helped increase my understanding of REST and its 5 core principles. I am by no means an expert on REST just because of this blog, but it has certainly helped prepare me to learn more about it in the upcoming class activities.