Vish's Journey in Computer Science

While going through different resources on API Development, I came across a blog post from Stoplight titled “API Design Patterns for REST Web Services.” Stoplight Blog – API Design Patterns for REST Web Services. I decided to write about this one because it connects directly with what we’ve been discussing in class about Design Patterns for REST API’s under the aegis of Professor Wurst. I’ve always wanted to understand how professional developers make APIs that are easy to use and extend, and this article gave me a clearer picture of what good API design actually looks like.

The post starts by explaining that REST APIs are not just about connecting endpoints — they’re about defining patterns that make services predictable and consistent. It discusses important ideas such as resource-based design, the use of HTTP methods for specific actions (like GET, POST, PUT, DELETE), and how to organize URIs in a way that feels natural to users. It also highlights how consistent naming conventions and status codes can make APIs more reliable for anyone consuming them. One interesting point the author makes is that designing an API is a lot like designing a user interface, except the “user” is another program.

I chose this blog because it goes beyond the basics of how to make an API work and instead focuses on how to make one well-designed. The examples were simple but realistic, and the explanations didn’t feel overly academic or abstract. I could see how these design decisions connect with what we’ve learned about modularity, abstraction, and communication protocols in software process management.

Reading this made me realize that design patterns in REST APIs are as important as design patterns in object-oriented programming. They both aim to make software easier to understand and maintain. For example, I learned about the “collection pattern,” where a resource like /users represents a group of items, and /users/{id} represents an individual. This pattern keeps the structure clean and predictable. I also learned how misuse of HTTP verbs (like using POST for everything) can make an API confusing or harder to scale later.

Personally, this article helped me connect classroom theory with real-world engineering practice. It changed how I think about building web systems — not just as code that works, but as something other people will depend on. In my future projects, especially my capstone work and the “Investment Wisdom” app I’m building, I plan to use these principles when designing backend endpoints. I’ll pay attention to consistent URIs, proper status codes, and resource naming so that my APIs feel professional and well-structured.

Overall, this blog was a great reminder that clarity and consistency matter as much as functionality. It showed me that designing a REST API is an act of communication — between developers, systems, and even future maintainers.