Thinking in REST API

When I first touch this terminology, I feel so confused because almost all the blogs shows the REST API is good for Decoupled Integration. I was thinking the MVC also do the decoupled Integration separates the front-end (view) and the back-end (controller and model) . So why we still need. And today I gonna organize my understanding in this field.

I. A scenario

Characters:

  Mrs. Thompson: The elderly and dedicated librarian.

  Cyan: A local software developer and regular library patron.

Setting:

 The town's beloved library, a cozy place filled with shelves of books and an old computer system for managing checkouts and returns. Cyan is willing to help Mrs. Thompson to update the old system. He chooses a conventional approach where the front-end and back-end are closely integrated. The community loves the new system. Who wants to more if life can just be this.

The Challenge:

However, with more people using this platform more demands appear, like adding a feature to reserve books online, requires significant effort. And because the new database pattern is designed , so Cyan must update both the front-end and back-end simultaneously, ensuring they work in harmony. So Cyan decide to use the new tech knowledge (He is not a senior expert, just learned) REST API to solve those demands.

Implement:

When Cyan deploy. And now even the new function need we change the database, add table or create new properties. It won't effect the front-end, even we didn't change anything on it. For example, if a back-end method returns a new data format, the corresponding JSP/Thymeleaf templates in the front-end might don't need to be rewritten to accommodate this change.

II. The boring but necessary conclusion

Also back to the first question. MVS also seperates the front-end and back-end and what's diff?

Even though Spring MVC separates the front-end (view) and the back-end (controller and model), they are often tightly integrated. For instance, the view layer might be designed to expect data in a specific format or structure directly from the back-end. If the backend logic changes – say, the structure of the data model – this can directly impact how the data needs to be handled or displayed in the frontend.

• Scalability: Both ends can scale independently based on their specific load and requirements.

• Flexibility in Development: Teams can choose the best technology stack for each side without being constrained by the other's choice.

• Easier Maintenance and Updates: Changes on one side, like redesigning the UI or updating business logic, generally don’t require changes on the other side.

• Focused Expertise: Developers can specialize in either front-end or back-end technologies, leveraging their strengths to build more effective solutions.

Alright! We have captured the essence of the REST API approach quite well. So much for it.