Week-13: 12/2/2024

Understanding software architectural patterns is critical in the software development industry for creating strong, scalable, and maintainable products.

A recent Turing blog post, “Software Architecture Patterns and Types,” has been useful in solidifying my understanding of this important concept. This article provided a comprehensive overview of various patterns, including monolithic, microservices, event-driven, layered, and serverless architectures. The article clearly gives explanations of each pattern’s design principles, advantages, and limitations.

For instance, while monolithic architectures offer simplicity, they often struggle with scalability. On the other hand, microservices excel in scalability and allow for independent deployment but can introduce complexity in maintenance and debugging. The article also explores emerging trends like serverless architecture, emphasizing their importance in modern cloud-based systems.

The practical examples and concise explanations in the article made it extremely relevant to what I learned in my classes, particularly my software construction, design, & architecture class. The discussion on system scalability and maintainability directly aligns with the topics we’re covering.

One of the most valuable takeaways for me was the emphasis on aligning architectural decisions with business objectives. The article effectively illustrates that a microservices architecture, while attractive for its scalability, might be overkill for a small-scale project. This resonated strongly with my recent experience in a group project where we debated between microservices and a layered design. Reflecting on the deployment and dependency management challenges we faced, the article validated our decision to opt for a simpler layered design as a better fit for our project’s scope.

Furthermore, the article’s discussion of serverless architecture was truly eye-opening. I had previously held a somewhat simplistic view of serverless as a universal scaling solution. However, the article shed light on its potential drawbacks, such as vendor lock-in and latency issues. This more nuanced perspective will undoubtedly inform my approach to future projects, encouraging me to critically evaluate new trends before jumping on the bandwagon.

Moving forward, I intend to apply this knowledge by diligently assessing the specific needs and constraints of each project before selecting an architectural pattern. For instance, when tackling a high-traffic e-commerce site, I would now consider employing an event-driven architecture to effectively handle asynchronous data flow. Alternatively, for smaller projects, I would advocate for a monolithic or layered approach to minimize overhead.

By understanding the trade-offs inherent in different architectural patterns, I feel better prepared to design and build software systems that are not only functional but also scalable, maintainable, and aligned with business goals.

Blog link: https://www.turing.com/blog/software-architecture-patterns-types

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

This week’s post will cover REST APIs, Representational State Transfer Application Programming Interfaces. One of the main key principles of RESTful APIs is the seperation between the frontend UI the user interacts with and the backend server. Postman’s blog highlights this as, “The client’s domain concerns UI and request-gathering, while the server’s domain concerns focus on data access, workload management, and security”. The primary purpose of REST APIs is to allow different software systems to interact and exchange data over the web. REST mainly focuses on stateless communication, where each request from a client contains all the information needed for the server to process it.

REST APIs use HTTP methods and standard URL structures to enable communication between clients and servers. HTTP methods play an essential role in REST APIs. These methods correspond to CRUD (Create, Read, Update, Delete) operations in software. The POST method is used to create, while GET retrieves data from the server. PUT and PATCH are used to update existing data, with PUT replacing the entire resource and PATCH modifying specific parts. DELETE removes data. In addition, REST APIs use status codes to indicate the outcome of an operation, For example, a 200 status code indicates a successful operation, 201 signifies resource creation, 404 means a resource was not found, and 500 represents a server error. Including appropriate status codes in API responses helps clients understand the results of their requests and handle errors effectively.

The blog post I researched by Postman highlights how REST is widely used across various industries. For example, e-commerce platforms use REST APIs to manage product information and process orders. Social media applications utilize REST APIs to handle user profiles and posts. Cloud services often provide REST APIs to allow developers to interact with their resources programmatically. The blog also mentions another type of API called SOAP, standing for Simple Object Access Project. SOAP is considered a protocol, while REST is considered a set of guidelines. Unlike REST which uses methods like JSON, URLs, and HTTP, SOAP uses XML for sending data. One of the main reasons why SOAP might be preferred over the more popular REST is because SOAP supports WS-Security, which provides a framework for securing messages, including encryption, digital signatures, and authentication. This makes SOAP more suitable for applications handling sensitive data. Corporations like banks and hospitals dealing with sensitive user information could utilize to prevent information breaches.

These APIs provide a consistent way for systems to interact and exchange data while adhering to a set of well-defined principles. By understanding HTTP methods, status codes, and data formats, developers can create APIs that users can understand and use.

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

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.

REST APIs are essential of todays software development, this helps applications to communicate across platforms. I read the blog post Best Practices for REST API Design on the Stack Overflow blog, which provided advice on designing APIs that are efficient, secure, and user-friendly. This post furthered my understanding of “RESTful” principles.

Summary

The blog post outlines several key principles for designing REST APIs effectively. It begins by stressing the importance of a well-defined URL structure that reflects the resource hierarchy and uses nouns instead of verbs. For instance, /users/123/posts is a clear and intuitive way to access a user’s posts.

It also highlights the necessity of using standard HTTP methods (GET, POST, PUT, DELETE) to maintain consistency, along with proper status codes to provide meaningful feedback to clients. The post delves into techniques for handling query parameters, versioning APIs to ensure backward compatibility, and implementing pagination for large datasets. Security and performance are emphasized as critical considerations, with recommendations to use HTTPS and apply caching strategies.

Why I Chose This Resource

As we did POGILs in class, I frequently ask myself scenarios where creating a robust REST API are most essential. This blog post stood out because it bridges theory and practice, directly applicable to homeworks and future projects.

Reflection

The blog post reinforced several concepts I’ve encountered, such as the importance of clear URL structures and consistent use of HTTP methods. However, it also introduced new ideas that I hadn’t fully understood as much, such as the role of API versioning in preventing disruptions for existing users when introducing updates.

One particularly impactful takeaway was the emphasis on client feedback through proper HTTP status codes. In my past in class activities, I’ve realized that it is imporetnat for an API to clearly communicate success or failure states, yet I hadn’t prioritized this aspect. The value of using codes like 201 Created for successful resource creation or 400 Bad Request for errors, enhancing user experience.

Future Work

Going forward, I plan to apply these best practices to my API design tasks. For instance, in my upcoming assignments or personal projects, I will ensure that URL structures are logical and intuitive, aligning them with its resourced relationship. Additionally, I’ll pay closer attention to implementing proper status codes and securing APIs with HTTPS to protect sensitive data, such as ID or SSNs…

This resource has also inspired me to explore tools like Postman or Swagger for testing and documenting APIs.

Conclusion

The blog post Best Practices for REST API Design not only refreshed my technical knowledge but also provided ideas for creating APIs that are robust, secure, and user-friendly.

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

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

Modern web applications are built on top of REST APIs, which provide the essential connection between the client and the server. This week, I discovered a blog called “Best Practices for REST API Design” by John Au-Yeung and Ryan Donovan which outlines important techniques for developing secure, performant, and user-friendly APIs. Because JSON is widely accepted and lightweight, it promotes its use as the standard data format. While HTTP methods like GET, POST, PUT, and DELETE determine the action, logical endpoint architectures that rely on nouns rather than verbs are crucial for clarity. Although it improves readability, resources should be kept simple to prevent complexity.

The blog discusses how to handle problems politely by giving easily comprehensible error messages to facilitate debugging and employing relevant HTTP status codes (e.g., 400 for Bad Request, 404 for Not Found). It also highlights the need of using query parameters for pagination, sorting, and filtering when handling big datasets. For protecting APIs, security measures including role-based access control, SSL/TLS encryption, and the least privilege principle are essential. Although caching is emphasized as a way to improve performance, developers should make sure it doesn’t produce stale data. Lastly, it is advised to version APIs, frequently using prefixes like /v1/, in order to guarantee backward compatibility and permit incremental enhancements.

Since we’ve been learning about REST API design in class, I chose to read a blog about it in order to gain a deeper understanding of best practices. In addition to explaining each essential aspect of REST API design, such as JSON usage, appropriate endpoint naming, error handling, security, caching, and versioning, I selected this blog because it also provides code blocks as examples, which helped readers understand and visualize the concepts more clearly.

What caught my attention the most was the part about using logical nesting for endpoints. It described how APIs are made easier to use and comprehend by grouping relevant endpoints. It also made the point that endpoints shouldn’t replicate the database’s structure. This increases the security of the API by shielding private data from attackers. I became more aware of how endpoint design may affect security and usability after reading this. This demonstrated the significance of properly planning endpoint architectures.

This article impacted my perspective on API design by emphasizing the necessity of striking a balance between usability and simplicity. I want to use these ideas in future projects by making solid security procedures, efficient error handling, and well-defined endpoint structures top priority. By using the strategies covered in this blog, I intend to create APIs that are effective and simple for developers to use, guaranteeing that they can be maintained and offer a satisfying user experience throughout time.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Similar to SOLID, GRASP is an acronym for a set of design principles used in object-oriented programming to clearly define responsibilities within a software system. GRASP stands for General Responsibility Assignment Software Patterns, and focuses on 9 different patterns or principles. A blog on kamilgrzybek.com called “Grasp – General Responsibility Assignment Software Patterns Explained” does a really good job at explaining all nine of the different patterns, as well as gives helpful examples of each. According to the article, “GRASP is a set of exactly 9 General Responsibility Assignment Software Patterns. As I wrote above assignment of object responsibilities is one of the key skill of OOD. Every programmer and designer should be familiar with these patterns and what is more important – know how to apply them in every day work (by the way – the same assumptions should apply to SOLID principles.” This quote shows that the GRASP principles are just as important to know as the SOLID principles. I think that everyone should learn the GRASP principles alongside the SOLID principles, and I plan on trying to use them in the future.

The nine principles consist of the following:

Controller
Creator
High Cohesion
Indirection
Information Expert
Low Coupling
Polymorphism
Protected Variations
Pure Fabrication

Controller tends to represent the device that the software is running within, such as the overall system. It also represents a use case scenario within the system operation occurs. Controller depends on high level design of the system being used, but generally we need to define the object which orchestrates the business transaction before it is processed.

Creator is a hard principle to explain. I think the example that the article gave is helpful. “Problem: Who creates object A? Solution: Assign class B the responsibility to create object A if one of these is true (more is better): B contains or compositely aggregates A, B records A, B closely uses A, B has the initializing data for A.”

High cohesion is how well the elements in a class work together. If a class has low cohesion, then it has a lot of unrelated data or behaviors inside of it. Classes with high cohesion, meaning it has data and behaviors that are all related to each other, are a lot more efficient.

Indirection avoids direct coupling between two or more things and allows an intermediate object to mediate other components.

Information expert assigns a class the responsibility of holding all of the information needed to fulfill the object and its needs.

Low coupling is when objects are more independent and isolated, rather than being completely dependent on other parts of the system. This helps reduce the risk of breaking the system.

Polymorphism is an essential principle of OOD. It allows different types of objects to be treated as a single type.

Protected variations identify points of predicted instability and assign responsibilities in order to create a stable interface around them.

Pure fabrication assigns a highly cohesive set of responsibilities to an artificial class that doesn’t represent a problem domain concept when you don’t want to violate high cohesion and low coupling.

Link: https://www.kamilgrzybek.com/blog/posts/grasp-explained

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Throughout the year we have used REST API in class more and more. Through the microservices kit activities I found more interest in the use of REST API. I sought out more information on them to expand my knowledge through an article on REST APIs. The article I found is REST APIs: How They Work and What You Need to Know by Jamie Juviler

The article begins by explaining the importance of REST APIs. They are a widely used framework that allows applications to communicate over the web by following a set of design principles. The article explains it is used to enable data sharing and integrations between systems, allowing software to interact with external services, improving functionality and user experience. The article continues by explaining how they work. By allowing clients to make requests to a server for resources, the server then responds with the current state of the requested resource, usually in a standard format like JSON. The API can also allow clients to modify or add resources on the server. The article explains there are six key principles to know:

1. Client-Server Separation: REST APIs separate the client and server, meaning that the client can interact with the server without needing to know how the server works internally.
2. Uniform Interface: RESTful APIs require a standardized way of interacting, usually through these HTTP methods: GET: Retrieve data. POST: Create new data. DELETE: Delete data. PUT: Update existing data.
3. Stateless: Each request to the server is independent and must contain all the information necessary for the server to fulfill the request.
4. Layered System: In a REST API, there can be intermediary layers (e.g., security layers, load balancers, or caching layers) between the client and the server. These layers should not impact the client-server communication and should be transparent to the client.
5. Cacheable: Responses from the server may be cacheable, meaning that the client can store the data locally and avoid repeated requests for the same resource.
6. Code on Demand (Optional): This optional feature allows servers to send executable code (like JavaScript) to the client, enabling the client to execute this code locally.

The article then explains the benefits of REST APIs, which include flexibility, scalability, interoperability, simplicity, and cost-effectiveness. Juviler then explains how to set up REST APIs with an admin and the article concludes with some examples of the use of REST APIs. 

Rest API has become something very important in class and because of recent assignments I wanted to learn more. Through this blog I understand REST more thoroughly, and the reasons for using it. I understand its feasibility and use for microservices back-end architecture as seen in Thea’s Pantry.

Source:

https://blog.hubspot.com/website/what-is-rest-api

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

This week I wanted to blog about Rest API. The repository that we have been working on in class has a decently large backend that uses a wide variety of methods to act as a good example and introduction of Rest API. I wanted to look into it and try to find more examples to look at and get a better understanding by looking at implementations that either had a different format or was used for different purposes. While looking I found a blog that detailed the documentation that developers have made a standard to put with code that aids in understanding.

The article starts off with some common mistakes that can really decrease the effectiveness of your documentation such as not enough examples, the lack of English explanations, and unmaintained documentation. As aspect that the article touches upon is that the documentation should be written to be understood by entry level developers, which makes sense as your implementation shouldn’t be opaque to the users. The article provides a survey taken by web developers that ranked the most desired features of API documentation, and ranks examples, status, and error messages in the top five. This makes sense as these are some of the things that contribute most to being able to understand already existing code. Spec-driven development is also explained here and talks about using software like Swagger to keep track of and simplify your code to easily understand how the program uses the data. The blog also puts emphasis on the industry standards that should be used, and it goes a long way to help users get a grasp of new code when they start to look at new projects.

This post was helpful in understanding how to read other repositories of API, especially as it was written in the form of the writer’s or maintainer’s point of view. Although I have not yet and don’t plan to yet, write and document an API designed by myself, this write-up was equally descriptive for explaining how to read the documentation. I think that this is an extremely useful skill to have because, like in our class assignments, we won’t always be designing something from the ground up and so we need to understand what is already there. The web page had lots of pictures to illustrate the point they were making and to provide examples. It always helps to learn more of these industry standards to be better prepared for real world or out of classroom applications and strengthen your skills as a programmer.

Original Blog Post – How to Write API Documentation

From the blog CS@Worcester – Computer Science Blog by dzona1 and used with permission of the author. All other rights reserved by the author.