The article I read this week was called “The Art of Writing Amazing REST APIs” by Joy Ebertz. In this article, Joy explores the principles for designing effective REST APIs. It discusses key practices such as naming conventions, including IDs and types, ensuring resource stability, and bridging gaps between current and ideal API states. I’m going to get into some interesting points or ideas she has, and talk a little bit more about them. To wrap it up, I will explain how I think it could be beneficial to take, or at least consider, the principles she describes and apply them to a project down the road.

The first thing she talks about, which I believe is one of the more important things she brings up as well, is consistency. It is the foundation to writing great REST APIs. Consistency can be, and should be, applied to every aspect of writing REST APIs as, when everything is consistent, confusion will be kept to a minimum which should be what everyone is aiming for. If one endpoint returns user_ID while another returns simply ID, you can see where confusion could occur. Thus, standardizing these things can make everything much more efficient.

Another point she mentions is that every resource should include a unique ID and Type field to ensure clarity/stability. Unique IDs prevent ambiguity, enabling resources to be fetched or referenced consistently and effectively. Including a type prepares APIs for future flexibility, such as supporting multiple resource types in a single response.

Joy talks about many different principles and ideas to writing REST APIs but the previously mentioned principles were a couple of the more important ones I believe, as well as just my favorite ones in general.

Career-wise, I think applying these principles would be very smart to do. Shooting for an extremely consistent REST API benefits everyone involved with it, and using unique IDs and Type fields only produces further benefits. Applying all the principles she mentions in the article would certainly be the best way, or likely one of the best ways, to write REST API, but obviously different people may find different things they like better so there may always be some differences in opinion over writing a good REST API. If anything, you should at least take from the article the principles she presents and try to apply them, in one way or another, to future writing as it would really only advance your skill on the matter regardless. This is certainly something I will try to apply given the opportunity.

https://jkebertz.medium.com/the-art-of-writing-amazing-rest-apis-dc4c4100478d

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

In the past few weeks, we’ve been learning and working with REST and how it ties into the larger picture of software architecture. I found this section confusing at times but mainly interesting thanks to the connection to personal experience. Once I realized that this is essentially the behind-the-scenes of those HTTP errors I’ve seen all my life, I was excited to learn more. 

Web services that adhere to REST are called RESTful APIs or REST APIs for short. REST API is a UI (uniform interface) “that is used to make data, content, algorithms, media, and other digital resources available through web URLs” (Postman). They are defined by three main aspects: a base url, a media type for any data to be sent to the server, and standard HTTP methods. There are four HTTP methods that are generally used in REST APIs:

• GET: This method allows for the server to find the data you requested and sends it back to you.
• PUT: If you perform the ‘PUT’ request, then the server will update an entry in the database.
• POST: This method permits the server to create a new entry in the database.
• DELETE: This method allows the server to delete an entry in the database.

These methods will have different effects depending on whether it is used to address a collection or an element (Postman). 

The part of REST that I found most interesting and that I’ve seen before were the HTTP response codes. In the case that one tries to go to a website and all they are met with is a white screen with black text stating “404: Error” followed by some details, that is a response code. Response codes will slightly differ depending on the HTTP methods used but most common ones include: 

• 200 OK
• 404 Not Found
• 400 Bad Request
• 500 Internal Server Error

I found this topic to be pretty interesting and honestly necessary in the case that one works with the web. Knowing the internet and my luck, I’m sure to encounter many of these errors for the foreseeable future and it’ll serve as a reminder to what I’ve learned about REST.

Side Note: Just the other day, when I was trying to log into Blackboard, I was met with a 404 error. I thought I could just reload the page or open a new tab and get into Blackboard but I was still getting the error. It took about five minutes before I could actually log in. I realized that knowing the details of these HTTP responses doesn’t make them any less annoying.

Source: https://blog.postman.com/rest-api-examples/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

Brygar’s principle of Simplicity resonates with Abstraction, as both focus on reducing complexity and emphasizing essential features. For example, an abstract Shape class might define a method draw(), but the specific implementation (how a circle or square is drawn) is handled in the subclasses Circle and Square. This simplifies the user interface by exposing only the necessary functionality.

Consistency aligns with Encapsulation, which involves bundling data and the methods that operate on it into a single unit and controlling access to the object’s internal state. For example, a Student class might have private fields like name and age. These fields are accessed or modified only through controlled public methods like getName() or setName(), ensuring that the class remains consistent in its behavior.

Modularity is closely related to Polymorphism, which enables objects of different classes to be treated as objects of a common superclass. By treating different objects as instances of the same class or interface, we can add new types without modifying existing code. For example, the Shape interface could allow the addition of new shapes (like Rectangle or Triangle) without altering the code for existing shapes.

Finally, Reusability directly connects with Inheritance, as inheritance allows one class to inherit properties and behaviors from another, making it easier to reuse and extend code. For instance, a Bird class could serve as a parent for Parrot and Eagle classes, where the child classes inherit common attributes like wingspan and methods like fly().

This blog post helped me understand how these design principles connect to each other. The assignment’s focus on defining the OOD principles and understanding their importance has deepened my appreciation for Abstraction and Encapsulation as tools for simplifying and protecting code. I now feel more confident in applying these principles to make my software designs both flexible and maintainable.

This blog post made me understand how it all connects. I now have a clearer understanding of how to approach system design in a more structured and efficient way. By focusing on Reusability and Simplicity, I’ll be able to write code that is easier to maintain and scale over time.

Link to the Resource:
Four Design Principles by Ivan Brygar

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

While writing software it is important to know, how to maintain clean and understandable code. Despite best efforts, developers can unintentionally introduce code design smells precise indicators of deeper design problems. While these smells don’t directly cause bugs, they reduce code readability, maintainability, and scalability.

In class we learned the 6 common Design Smells, so I referenced the class materials and found an helpful article on Refactoring Guru. This webpage offers a practical explanation of common smells such as long methods, large classes, feature envy, and shotgun surgery.

Why I Selected This Resource

The reason why I chose this resource resonates with the principles we’ve covered in our class on software design and architecture. Its structured, accessible approach demystifies complex design issues, offering developers clear steps to refactor and improve their code. I’ve often seen myself facing challenges and struggling with tangled code where debugging or adding features feels almost somewhat overwhelming. These tools and insights help a and provide a roadmap for addressing such challenges systematically, and thoughtfully throughout the design process.

My Reflections on the Resource

The discussion on bloaters, like long methods and large classes, I think this was particularly something worth learning. These smells arise when a method or class tries to handle too much, violating the Single Responsibility Principle. I realized that in past projects, I’ve struggled with methods growing unmanageably large as features were added. Refactoring Guru suggests breaking these methods into smaller, more focused ones using techniques like extract method, improving both readability and reusability.

Another key takeaway was the concept of change preventers, such as shotgun surgery, where making a small change requires altering code in multiple places. This often signals that responsibilities are poorly distributed across the system. The resource recommends consolidating functionality into a single class or method, reducing the risk of errors and making future updates more straightforward.

Applications for Future Practices

Refactoring Guru’s emphasis on identifying smells early and refactoring incrementally aligns well with agile development practices. Moving forward, I plan to use this more than one of these materials as a checklist during code reviews to spot and address issues proactively. Techniques like extract method, extract class, and move method will hopefully become part of my tools for tackling coupled code. By continuing improving my skills to detect and refactor code smells, I want to create cleaner, more sustainable codebases that will be easier for both my team and future developers to work with. Thank you for reading my blog post and I hope you learned some

https://refactoring.guru/refactoring

https://refactoring.guru/refactoring/smells

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

Intro

Imagine inheriting a massive, poorly designed codebase. Every change you make breaks something else. For software developers, such nightmares can be avoided by adhering to the SOLID principles, a foundational guideline for creating maintainable, scalable systems. These principles are a must-know for any software developer seeking to improve the quality of their work. They provide a roadmap for developers to create cleaner, more maintainable codebases, which is why I was drawn to this resource

Blog Summary

The blog goes through each of the five principles, explaining what they are, why they are important, and giving a code examples utilizing each one.

1. Single Responsibility Principle (SRP): A class should have only one reason to change, ensuring focused and cohesive functionality. The blog illustrates SRP with an example of separating user management from content creation, showing how this approach simplifies debugging and enhances code clarity.

2. Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification, promoting adaptability without risking existing functionality. For OCP, the blog demonstrates how using inheritance and interfaces allows developers to add new functionality, using Square and Rectangle classes inheriting from the Shape base class.

3. Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering the correctness of the program. The example provided for LSP highlights how properly designed subclasses, such as an Eagle and a Penguin inheriting from a Bird class, ensure seamless substitution without breaking the program.

4. Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use, encouraging lean and specific interfaces. In discussing ISP, the blog uses an example of splitting a large interface into smaller, more specific ones, ensuring that classes only implement what they actually need.

5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules but instead rely on abstractions. For DIP, the blog explains how decoupling high-level modules from low-level details using abstraction layers, like interfaces, makes the codebase more flexible and easier to maintain.

Why I chose this resource

I selected this blog to write about because it breaks down each principle in a concise way, clearly explaining each one in a way that is easy to understand at all levels. It’s a great resource to quickly go back to when you need a refresher on any of the principles.

Reflection on SOLID

After learning about SOLID, I see that it might take an extra step of thinking to adhere to the principles at first, but I think it’s well worth it for the resulting code structure. The easy way to code is messily throwing together code that works without a second thought, but doing that is very dangerous for the longevity of a program. I believe that after following SOLID for a while it will become second nature and will become the natural way of coding, which is why I think it’s important to learn about SOLID early and consciously until it does become a subconscious practice. In one of my past projects, I struggled with messy code that implemented multiple responsibilities in one class. Debugging it was a nightmare, but had I known about the SRP principle it could have been avoided entirely. Reflecting on these principles has already influenced how I plan on approaching my code, and I’m eager to incorporate them into my future work.

Future Application

Given the importance of SOLID principles for large-scale software, I believe it’s essential to internalize and apply them in future projects to thrive in the software development space. By crafting modular classes and reducing dependency, I aim to create services and systems that are easy to maintain and adapt as requirements expand and evolve.

Citation

“Essential Software Design Principles You Should Know Before the Interview” By Arslan Ahmad

https://www.designgurus.io/blog/essential-software-design-principles-you-should-know-before-the-interview

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.