Skip to main content

REST API Design

This week on my CS Journey I want to focus on REST API Design. In my last blog, I talked about how an API request works and how to be able to read the API documentation and use it effectively. In this blog, I will be emphasizing briefly the key constraints to REST API design. There are six important constraints to the design. Which are: Client-Server, Stateless, Cache, Uniform Interface, Layered System, and Code on Demand. Together, these make up the theory of REST.

Starting with client-server constraint is the concept that the client and the server should be separate from each other and allowed to evolve individually and independently. In other words, a developer should be able to make changes to an application whether on the data structure or the database design side at the same time it is not impacting the client server side. Next REST APIs are stateless, meaning that calls can be made independently, and each call contains all the data necessary to complete itself successfully. The other Constrain is Cache, since a stateless API can increase requests and handles large loads of calls, a REST API should be designed to encourage the storage of cacheable data. That means that when data is cacheable, the response should indicate that the data can be stored up to a certain time. 

The next constrain is Uniform Interface, having a uniform interface that allows the client to talk to the server in a single language. This interface should provide standardized communication between the client and the server, such as using HTTP with resources to CRUD (Create, Read, Update, Delete). Also, another constrain is a layered system. As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility. In REST API design, the same principle holds, with different layers of the architecture working together to build a hierarchy that helps create an Application. Also, A layered system helps systems to increase flexibility and longevity and it allows you to stop attacks within other layers, preventing them from getting to your actual server architecture. Finally, the least known of the six constraints is Code on Demand which allows for code to be transmitted via the API for use within the application. Together, these constraints make up a design that operates similarly to how we access pages in our browsers on the World Wide Web.

Overall, I learned the most important aspects of REST API Design. The blog was certainly helpful to understand the key constraints very well. I have only mentioned the main important parts of it. I highly recommend everyone taking a look at the source below. 

Source: https://www.mulesoft.com/resources/api/what-is-rest-api-design

Comments

Popular posts from this blog

Apprenticeship Patterns Blog – Learn How you Fail

For this week’s blog post, I read the section “Learn How You Fail” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The quote beginning of the section is what stood out to me the most. It says, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.” The section talked about how sooner or later you may face failures but the right thing to do is push forward at the boundaries and learn to overlook the mistakes you have faced. In our field, we face many failures but that is not holding us back to accomplish the goals we have set for ourselves. The author mainly talked about becoming conscious of the things that trip you but allow yourself the choice of working to fix the problems that are cutting the losses. One of the most important things to do when you face failure is to accept it and investm

Apprenticeship Patterns Blog - Expand Your Bandwidth

For this week’s blog post, I read the section  “Expand your bandwidth” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The main reason this pattern was Interesting was because of a quote that stood to me. It was “[L]earning about what we don’t know is often more important than doing things we already know how to do.” This quote is so accurate. Especially in a technology-driven world, it is always evolving. so, developers must learn new technologies and software’s all the time. It is important to prioritize learning what you do not know. Later in the section author mentioned the overwhelming aspect of learning new information and expanding your ability, it is important to expand your knowledge and experiences in multiple dimensions such as: reading a book, social media, blogs Groups, and other academic resources. The second half of the pattern talked about how Once you understand how to Expand Your Bandwidth, the next step is to understand wh

Testing with Mockito

During class, we have been doing many testing methods including Junit 5 and for the past two weeks we have been using Mockito, so for today’s blog, I want to focus more on the framework and testing with Mockito. Before we get started let us talk about what is mocking. Mocking is a process of developing the objects that act as the mock or clone of the real objects. In another word, mocking is a technique where mock objects are used instead of real objects. The purpose is to isolate and focus on the code being tested. Mock uses objects such as Fakes, Stubs, and mocks. A fake object has working implementation but takes shortcuts which makes them not suitable for production. Stub object usually does not respond to anything outside that is programmed in for the test. Mocks are objects that are preprogrammed with expectations which form a specification of the call that is called to receive. Now let us move on to what Mockito is, Mockito is a java based mocking framework that internally use