Category Archives: Blog-Quarter-3

Learning More About REST API

I have been learning about REST API. There is UUID. It stands for Universally Unique Identifier. It is a combination of numbers that represent a user, keeping them anonymous. REST APIs adhere to the constraints of their RESTful architecture. They contain a base URL, a media type and standard HTTP methods like GET, PUT, PATCH, POST, and DELETE. POST creates new entries in a collection. PATCH updates a certain member in a collection. Think of sewing a patch in a part of a blanket. You can’t sew a patch over a whole blanket. GET retrieves (or gets) information of a collection or specific member. POST creates a new entry like making a post to add to the sea of posts online. PUT can replace a collection, replace a specific member or change an aspect about a member. There are also codes associated with the outputs of these commands. There is 200 which means that a command was executed successfully. There is 201 which means a POST has successfully created an entry. There are unsuccessful requests like 400 which means that the request itself has an error, 500 which means that the server could not do the request and 404 means that it cannot do what is requested. That is the bulk of what I know.

The main reason for the post is to learn more about REST APIs. I am using this website as my source: Debugging APIs Best Practices for Product Managers

This article seems to have more than the basics. Most of the other articles just go over what I know. This article goes over how to debug APIs. Debugging in general is a very important skill for any coding language. In fact, most of the time a developer spends on a project is debugging.

The main thing I learned were the steps to debug API. I am going to connect this with REST APIs since it is the API I am familiar with. Step one is to identify the issue. This can be done using developer tools like Chrome Developer Tools. I believe that this is for more complex work since someone could just review the REST API. The second step is just to check the status error code. The third step is just delving in further depending on the status error code. For example, I get a 400 error. I could ask myself am I misspelled something or if my input is not properly structured. Think about step two as gathering information and step three is looking through it. The last step is experimentation. Essentially, use problem solving skills.

Overall, this article gave me a better understanding of REST APIs. I knew a few of the steps beforehand so it was not completely new. It was nice to learn that there are tools to identify problematic API. I will keep it in mind if I ever need to use it. Maybe, I will use it in a future web application development.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Continuous Integration and Its Role in Modern Software Development

As part of my work in CS-343: Software Construction, Design, and Architecture, I explored Martin Fowler’s article Continuous Integration: Improving Software Quality and Reducing Risk. The article explains how Continuous Integration (CI) has become a foundation of modern software development. I chose this topic because CI connects directly to what we learn in class about software design, testing, and teamwork, and I wanted to understand how professional engineers use it in real projects.

Why Continuous Integration Matters

Fowler defines CI as the practice of frequently merging small code changes into a shared repository, where each integration automatically triggers a build and a full suite of tests. This quick feedback loop helps developers detect and fix errors early, saving time and reducing costly bugs later. I found it interesting how CI transforms collaboration. Instead of waiting until the end of a sprint to integrate work, developers share updates several times a day, which keeps everyone aligned and encourages constant communication. This matches Agile values like transparency and adaptability.

How It Works in Real Projects

The article reminded me of how many real companies rely on CI tools such as GitHub Actions, Jenkins, or Travis CI. For example, open-source projects on GitHub often use automated pipelines that run tests every time someone submits a pull request. At larger companies like Netflix or Google, CI systems help maintain quality across thousands of code changes each day. These examples show that CI is not just a technical setup, it is a habit that promotes trust and shared responsibility among team members.

Challenges and Lessons Learned

Implementing CI is not always easy. Some teams struggle with broken builds, unreliable tests, or slow pipelines. Fowler points out that success depends on discipline and teamwork. Everyone must commit stable code, fix issues immediately, and write reliable automated tests. I learned that good communication is just as important as good tooling. Teams that treat CI as a shared value rather than a rule tend to build stronger collaboration and avoid finger-pointing when problems arise. Helpful resources such as the GitHub Actions Docs and Jenkins Website provide guidance for managing these challenges.

Key Takeaways

Continuous Integration stood out to me as more than just a process. It represents a mindset of accountability and openness. By integrating code regularly, teams reduce risks, deliver features faster, and maintain cleaner codebases. What I liked most about Fowler’s explanation was how he linked technical practices to human behavior, showing that consistency and trust are the real keys to quality software. Moving forward, I plan to apply these principles in my own projects by setting up automated builds and test workflows. CI will help me work more efficiently and confidently in any team environment.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.