Rest API and CS-343 are a duo that just sounds right. When trying to give to come up with a blog idea for such a class, I couldn’t picture a clearer GIF than our dear friend Patrick Star

I try my best to not compare but it is hard not to when I compare my blog process to CS-348 and made the sudden realization I have over a hundred ideas for that class.

However, in the short two-minute comparison, I realized that since my class was approaching MS-Billion-Gillion-Trillion in Micrroservice Activity, it would be a great time to take a deep dive into Rest API.

A lot of the articles I had a chance to come across I noticed to have lots of gaps in the information provided. Noticed in some there was missing clarification, simplified introductions, and Chat-GPT “Whats Rest API” money makers. REST API and API in a Nutshell. Deep Diving Into REST API by Krunal Chauhan offered the best of both worlds in offering me a crash course on Rest API and a challenging question started on the advanced side of such a topic.

Crash Course KNOWS:

1. Definition of API:
   • API stands for Application Programming Interface.
   • It acts as a software intermediary allowing communication between different applications or devices.
2. Need for API:
   • Necessary for communication with various devices and services.
   • Enables interaction with web browsers, mobile devices, and third-party software.
3. API Explanation (Metaphor):
   • Describes API as a mediator, like a waiter in a restaurant, facilitating communication between the client (user) and the backend (kitchen).
4. How API Works:
   • APIs communicate through rules/protocols.
   • Typically works over the internet via HTTP, built on top of the TCP/IP protocol.
   • Analogizes API communication to a customer (user) placing an order through a waiter (API) to the kitchen (backend).
5. REST API:
   • Represents a style of API architecture that uses HTTP and is user-friendly.
   • Introduced by Roy Fielding and is considered a standard protocol for web APIs.
   • Works with HTTP methods like GET, PUT, POST, and DELETE.

CRASH CROUSE DEEP DIVE:

1. Building Blocks of API:
   • API Interface Block: Defines specifications for the API, often using HTTP.
   • API Controller Block: Manages traffic, and handles authentication, and authorization.
   • API Runtime Block: Executes the business logic of the API.
   • API Data Bridge Block: Facilitates seamless access to shared data storage.
2. API Management:
   • Involves designing, publishing, documenting, and analyzing APIs in a secure environment.
   • Components include API design, API gateway, API store/developer portal, and API analytics/dashboard.
3. Types of API:
   • Open APIs (Public API): No restrictions on access.
   • Partner APIs: Requires specific rights or licenses.
   • Internal APIs (Private APIs): Used within a company for internal purposes.
4. REST API Architecture Components:
   • REST Client: Code or app accessing REST services.
   • REST Server: Offers API and resources.
   • REST API: Defines endpoints and methods.
   • Endpoint/URI: Specifies where to find a resource.
   • REST Request: Includes HTTP method, endpoint, headers, and body.
   • REST Response: The server sends a representation of the resource, often in XML or JSON.

I enjoyed reading these types of articles when the reading flow is smooth and coherent to the subject. If you can believe it or even if you check the article yourself, the summary above is my notes for the article and about how 99% of the article flowed.

A good chunk of the reading was a good reminder of things I already learned but there was also a few sections that required me to go back as we have not had the chance to talk in-depth about them.

Specifically, the Rest API Management as this was the first time I ever heard these terms before and was not a section we were able to cover just yet. Out of the article I was able to break down the Rest API Management into 4 sections.

1. API Design:
   • This block enables users, including developers and partners, to design, publish, and deploy APIs. It includes recording documentation, security policies, descriptions, usage limits, runtime capabilities, and other relevant information.
2. API Gateway:
   • The API Gateway acts as a gatekeeper for all APIs. It handles tasks such as routing requests, composition, and protocol translation. It enforces relevant API security policies, ensures authorization, and guarantees the security of requests.
3. API Store / Developer Portal:
   • This component provides a place to keep APIs in a store or catalog, exposing them to internal and/or external stakeholders. The API store serves as a marketplace where users can subscribe to APIs, obtain support from the community, and access other relevant information.
4. API Analytics/Dashboard:
   • API management solutions offer analytics and dashboards that allow users to monitor API usage, load, transaction logs, historical data, and other metrics. This information helps in understanding the status and success of the available APIs, facilitating data-driven decision-making.

Now I’m not sure why I found this part so interesting and why I found myself watching a 30-minute YouTube video on how API dashboards work and operate, but hey whos going to judge? This is a section I believe we are going to cover/hope we do as it’s been a great experience learning how to build and read complicated APIs. I feel like I am ready to take another step and properly learn how I would manage one of these APIs that I created.

PS: “Advantages of API vs ******** ” (Stay Tuned)

Until Next Time

Source: https://medium.com/@krunalchauhan_/article-worth-reading-on-what-is-an-api-what-is-a-rest-api-and-deep-diving-into-rest-api-fea074dacaed

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

As a student navigating the intricate world of software development, stumbling upon Andreas Schöngruber’s insightful article on anti-patterns was like discovering a treasure map through the labyrinth of coding pitfalls. Titled “What Is an Anti-pattern?”, the article serves as a comprehensive guide to understanding, identifying, and avoiding anti-patterns in the software development lifecycle.
Schöngruber’s article begins by defining anti-patterns as deceptive solutions that appear effective but ultimately create more problems than they solve. These pitfalls manifest in various aspects of software development, from programming practices to methodological and testing phases. The article covers programming anti-patterns like Spaghetti Code, Lava Flow, Accidental Complexity, God Object, Hard Code, and Magic Numbers. It further explores methodological anti-patterns such as Premature Optimization, Reinventing the Wheel, and Copy and Paste Programming. The discussion extends to software testing anti-patterns like the Wrong Kind of Test, Testing Internal Implementation, and the Happy Path.

Why I Chose This Resource:

In the ever-evolving landscape of software development, understanding what to avoid is as crucial as knowing best practices. The article’s clarity in categorizing and explaining various anti-patterns appealed to me as a student eager to enhance my coding skills. It provides a roadmap to steer clear of common pitfalls and promotes a proactive approach to creating efficient and maintainable code.

Reflection on the Content:

As I delved into the programming anti-patterns, the concept of Spaghetti Code resonated with me. Schöngruber’s emphasis on modularity and readability struck a chord, prompting me to reflect on past coding practices. The discussion on Hard Code also resonated, making me rethink my approach to configuration management. The article prompted a realization that simplicity, adhering to the “Keep it simple, stupid” (KISS) principle, is not just a preference but a necessity.

Moving into methodological anti-patterns, the notion of Reinventing the Wheel made me reconsider some instances where I may have overlooked existing solutions. The discussion on Premature Optimization underscored the importance of balancing performance improvements with actual needs, a valuable insight for optimizing code efficiently.

Application in Future Practice:

Armed with the knowledge gained from this article, I envision a more discerning and proactive approach to my future coding endeavors. Recognizing anti-patterns will not only enhance the quality of my code but also contribute to a more efficient development process. I plan to integrate the principles discussed, such as modularity, simplicity, and avoiding unnecessary optimizations, into my coding practices. Additionally, the insights on testing anti-patterns will guide me towards more effective quality assurance strategies.

For those eager to navigate the labyrinth of software development with fewer missteps, I highly recommend reading Schöngruber’s article. It’s a valuable addition to any student’s toolkit, providing insights that transcend textbooks and delve into the practical nuances of writing robust and maintainable code. You can access the article with the link below.

https://www.baeldung.com/cs/anti-patterns#:~:text=Anti%2Dpatterns%20are%20the%20opposite,project%20management%2C%20and%20organizational%20behavior.

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

This week’s topic I decided to choose a blog post about the writing of clean code to correlate with what we’ve been learning in class. The blog post, published by Jacob On Software, details how the writer has been reading Clean Code by Robert Martin. This handbook identifies the significance of writing clean code, as well as, how to properly write readable and professional code. Jacob On Software takes a unique and effective approach to teach readers; refactoring one of his old projects. Jacob states in his blog post that during this project, he was forced to learn how to create a full stack web application in just three weeks, resulting in him rushing and writing not so clean code. The blog post highlights that other contributors working on his project will have strenuous time trying to decipher his messy code, hindering the development process and evolution of the software.

Looking at an image of the his code, we can see that the name of his functions are descriptive of what they accomplish, however the functions themselves have too many lines of code, which is a crucial aspect detailed in the Clean Code book. Having functions that are thousands of lines long makes it a nightmare to understand what the function is doing. Clean Code emphasizes that functions should be small and straight to the point. Jacob fixes his code by splitting up the function into smaller functions. Additionally, Martin’s Clean Code stresses that a function should do one thing. Previously, Jacob’s function was performing multiple operations like holding data and updating it. These operations were split up into their own functions, allowing others to instantly understand the purpose of these functions.

Further into the blog, Jacob talks about the formatting of his code. The more lines a file has, the harder it is to understand. Users only have a limited amount code that will fit on their screen at once. If the developer has to constantly scroll up and down through hundreds of lines just to understand your code, you are not writing clean code. The same can be said horizontally, lines in your code should not be extending off to the right of the screen.

I chose this topic because after looking at the examples of bad code and good code in class, I admit that most of my code that I’ve written in other classes would be considered bad code. Non-descriptive variable/function names and multiple operations in functions have definitely been a weakness in my code. It’s crucial to write clean code as software developer working in a team so other team members can easily understand your code. I plan to use this information as a guideline on how to write more descriptive and readable code in the future.

Blog Post: https://medium.com/codex/reading-clean-code-week-2-643641e4dc28

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

During our classes we discussed the definition, theory, values, team makeup, events, and artifacts of Scrum. I decided to focus on one of the events of Scrum within the Sprint called the Daily Scrum. The Daily Scrum was briefly described and we discussed how the Daily Scrum allows the team to inspect progress toward the Sprint Goal and to adapt the workload as necessary. What we didn’t do was discuss the best way to go about that. I wanted to understand the best practices for proper communication with team members in accordance with Scrum values. The blog “Ten Tips for More Effective Daily Scrums” by Mike Cohn helped with this by giving 10 helpful tips for how to conduct a Daily Scrum. Cohn specializes in agile processes and techniques and makes a living by helping companies build high performance teams.

After reading the tips, I could see that most of the points were prioritizing focus, one of the main values of Scrum. Most of the tips give solutions or show problems that arise that stop the Daily Scrum from focusing on the Sprint Goal. The problems it shows are what I assume to be problems that happen repeatedly for people new to Daily Scrums. They don’t talk about the current Sprint, talk about work done unrelated to the Sprint Goal, focus on unrelated details, and ramble. I liked how the author handled the issues. He pushes the idea that you should set ground rules or guidelines that everyone understands before conducting the Scrum. Having words or phrases that let the team know you might be rambling or for letting a person quickly explain that non-Sprint Goal work was done seemed like a very good way to professionally conduct a meeting. I would think it’s hard to tell someone that they are rambling more than they need to. To have a buzzer or code word established must help communication without hard feelings and allows everyone to be on the same page.

 I also appreciated prioritizing the use of certain words. Saying “impediments” instead of “blockers” or asking about what a person “accomplished” instead of what they “did”. I wouldn’t normally think to prioritize certain words while conducting a meeting, but his explanation on how it changes the team’s perspective on the work during the Sprint was enlightening.

This blog showed me that when communicating with your group, whether in a daily Scrum or not, there are simple ways to optimize communication. The tips given weren’t groundbreaking, but I can see various ways this could be used when communicating with others. Going forward, I plan on setting an outline of ground rules that the team agrees on so we can effectively communicate.

Link to “Ten Tips for More Effective Daily Scrums” by Mike Cohn – https://www.mountaingoatsoftware.com/blog/ten-tips-for-more-effective-daily-scrums#author

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

https://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

When it comes to sharing your work publicly, there are certain things you have to do in order to protect it, and you. Whether the work is a form of art, product, or even code, you have to put a license on it. The creator can put software licenses on their code to allow users to use it in certain ways, according to the license agreement. 

Software licenses are categorized into types, which are ranked from least restrictive to most restrictive. The least is the public domain license, which has no restrictions on your code, meaning anyone can do anything with it. Next is the permissive license, similar to the public domain one, except it has some restrictions on how users can use, modify and redistribute the code. The next one is the copyleft license, which also has restrictions on how to use, modify and redistribute the code, but it also states users must distribute the source code with it. The most restrictive is the proprietary license, which only allows users to use the code if they agree to an agreement, and does not allow them to modify or redistribute the code. Under each of these types, there are licenses that have their own extra requirements, so it is important to look at each one to determine which is a good fit for your code.

In this blog post, Ibrahim Ogunbiyi gives us 7 practices that can help with license management. Step one is documenting your procurement process, document where you purchased software, who did it, when, and other important details. Having documentation on software purchases is important for when you need to look back for information. Step 2, having a central list of all software licenses. If there are multiple departments in your organization, having a central list containing all software licenses is good to have. Step 3, understanding all software license agreements, reading through and understanding the agreements. Step 4, implementing a software license management tool. Having a tool to manage your licenses, tracking use, and optimizing use is really nice to have. This can also knock out step 5, regularly tracking license use, and step 6, keeping licenses accurate and up to date. The tool can do that for you, but sometimes, doing it yourself is nice. Step 7 is training employees about license management, which is important for an organization. Having everyone follow the same methods of management promotes uniformity, which makes things easier.

Although I may not belong to an organization that purchases software, I feel knowing these steps is good. Software licenses, or licenses in general, are scary and confusing. It’s not something you are taught in school, so having learned it in class was nice. I can’t quite relate to this just yet, but it is important to know management tips so that when the time comes, I will be ready. In the future, I know I will be coming back to refresh my mind on it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Whether you’re embarking on a new project or contemplating a shift in your development approach, deciding between Agile and Waterfall methodologies can be challenging. Selecting the right approach is crucial for the successful development of your project. In this blog, we will analyze the specifics of Agile and Waterfall methodologies to help you make an informed decision tailored to your project’s needs.

Understanding Agile

Ever wondered about the magic behind Agile Software Development? I have recently come across a blog on Agile development by Martin Fowler, a British software developer, author, and international public speaker on software development, who specializes in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming. The blog “Agile Software Guide” by Mr. Fowler takes you on a journey through its beginnings and the core ideas that makes Agile work. Written by someone who was there from the start, this blog unravels the secrets of Agile development. The author shares early memories of Extreme Programming and co-authoring the Manifesto for Agile Software Development that sets the stage for an insightful tour through the world of Agile, coming from a credible source who has seen it from its beginnings. The blog dives into the key concepts of Agile thinking, emphasizing how it differs from traditional software engineering. It breaks it down into two main points: being adaptable instead of sticking to plans, and focusing on people rather than processes. A simple breakdown that makes the essence of Agile clear. Mr. Fowler also talks about Agile plans being like a flexible baseline, changing as the project progresses. Unlike traditional plans that demand sticking to a set path, Agile plans are adjusted based on what’s happening. Success in Agile is all about the value the software brings, not just following a rigid plan. However, with all its advantages, the blog doesn’t pretend Agile is perfect. It talks about the challenges, like some practices being called “Agile” when they really aren’t. This honesty adds a dose of reality, reminding everyone to keep an eye on how Agile is actually being used. Agile methodology is often praised for its customer-centric, and flexible approach to software development. In Agile, projects are divided into small increments with minimal planning, and teams work in short cycles, known as iterations or sprints. The methodology emphasizes collaboration, customer feedback, and the flexibility to adapt to changing requirements in which results in continuous delivery of functional software, close collaboration between cross-functional teams, stakeholders, and the customers.

understanding Waterfall

Unlike Agile, the Waterfall methodology follows a linear and step-by-step approach. the project is divided into distinct stages where each stage build’s upon the previous one. The development process flows steadily downwards similar to an actual waterfall, through stages like requirements, design, implementation, testing, deployment, and maintenance. Each stage must be completed before the next one begins, and changes are discouraged once a phase is underway.

How to choose the right methodology? 

The choice depends on several factors, such as project requirements, team expertise, and customer involvement in your development process. If project requirements are clearly defined from the beginning, and changes won’t be necessary during the development process, then the Waterfall methodology could be the right choice for you. However, I personally believe that Agile methodology is usually the right choice for most projects.

In today’s world of constant change, adaptability is crucial in any developmental process. Additionally, based on my experience in various customer service jobs, I’ve realized that customers often don’t know exactly what they want. Therefore, having the ability to adapt if the customers’ needs changes’ slightly is incredibly important.

Agile Software Development: A Concise Overview. (2023). Retrieved from https://martinfowler.com/agile.html

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

I’ve been coding since around 2017, when I took my first Computer Science course in high school. Since then, I’ve worked on plenty of school projects and a couple of personal projects as well. Software testing had never been a thing I really bothered with meaningfully in this timespan, which is kind of fair considering that most of these projects and assignments weren’t really too complex. I would just print out results for each bit of code as I went along to make sure that the code I just wrote actually works, but I didn’t really go and write actual automated tests.

This semester, I had some exposure to standardized software testing when I worked on a homework assignment in my Software Design and Construction course that required me to adjust some code along with the tests that make sure the code works as intended with intended output. At first, I was sort of confused considering I had never worked with test files, but I appreciated the streamlined nature of this testing. We also had to read up on some software testing methods for a Scrum developer homework assignment we did for this class, Software Process Management.

Today, I wanted to research some software testing basics, and came across a post on IBM’s blog. The post goes over some reasons to software test (the importance of quality control for businesses, what testing even is, etc.) along with types of software tests and practices.

The different types of software tests are fairly easy to understand, and I’ve come across all of them in some capacity before. Acceptance tests ensure the system as a whole functions as intended, integration tests ensure that software components work as intended, and unit tests ensure the smallest testable snippets work as intended. Performance tests evaluate how well software works on different hardware, and stress tests check how much load the software can take without breaking. Regression tests see if new features harm the software at large, and usability tests evaluate how effective the software is for end-users.

Some good testing practices listed in the article are continuous testing, bug tracking, and service virtualization. Continuous testing is the practice of testing each build as soon as it’s available, fairly simple. Bug tracking is, well, bug tracking. The post mentions automated monitoring tools for tracking defects, but I sort of think of this in the sense of keeping an issues list on a git repository, as that’s what I’m more familiar with. Service virtualization is a little more complicated, it simulates functionality that hasn’t been implemented yet to reduce dependencies and test sooner.

What I’m mostly interested in is the applications of these practices, and I’ll likely look into it further at a later time. I understand these concepts fairly well, but the idea of automating tests, at least at my current understanding of it, sounds a bit daunting. I’m sure it saves a lot of time on larger-scale projects, where testing each piece of your code manually for multiple cases will take a lot of time. I’m interested to see what this looks like in an example.

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

During our Software Construction, Design and Architecture class, we’ve gone over a multitude of different design techniques, patterns and tools to ensure that we write quality code. We’ve also touched on some design / code smells and the concept of technical debt. While design smells can give you an indication of something that might be wrong with your code, whether in a small section or in the overall design, anti-patterns represent a much more obvious, prevalent problem in your code.

Some of the most common examples of anti-patterns I’ve heard in conversations I’ve had with my friends, classmates and even teachers in a joking matter, like spaghetti code, and copying and pasting code snippets from random repos (which isn’t just bad practice for coding, it’d also be possible to infringe upon licenses or the lack thereof placed on that code). I think the reason why these are fairly common among the circles I’ve been in is just because everyone has done it before for a school assignment or something, and it’s just funny to joke about.

Some anti-patterns are a bit more involved with designing software in a meaningful sense, though. In a blog post from Lucidchart, some other anti-patterns found in software development and design are golden hammers, god objects, boat anchors and dead code. What’s interesting about these is that they actually are actual manifestations of design smells, in the most obvious ways.

For example, a boat anchor is a piece of code that isn’t being used yet but might be used in a future version, maybe. This results in needless complexity, an addition that isn’t necessary and makes it harder to read your code. Dead code is similar, code that gets executed but isn’t even used in the output of a program, causing immobility. Using a golden hammer means you are using the same tool for a bunch of different jobs, thinking that it is the best tool for all cases. This contributes to fragility, needless repetition and opacity depending on the implementation one goes about with a golden hammer. God objects are similar in a sense, as they’re objects that do too much and are responsible for too many functions. This violates encapsulation principles that are good practice in software design, while also resulting in immobility, viscosity and possibly even more. Dead code

This reinforces the idea of checking for code smells and refactoring code as needed, because otherwise you will build upon a foundation that was fundamentally problematic, and the rest of your code will reflect it no matter how much better it is. This all ties into technical debt, and brings all of the software design principles, concepts and ideas together into a picture that says: please maintain your code cleanly!

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

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

In today’s digital landscape, REST APIs play a pivotal role in facilitating seamless communication between various clients and services. However, designing these APIs requires careful consideration of factors such as security, performance, and ease of use for consumers. In this blog post, we will delve into the key best practices for designing REST APIs that are not only easy to understand but also future-proof and secure.

Summary: The selected resource outlines essential guidelines for designing REST APIs. It covers crucial aspects like choosing the right data format (JSON), using nouns instead of verbs in endpoint paths, logical nesting for hierarchical objects, handling errors gracefully with standard error codes, and implementing features such as filtering, sorting, and pagination. The article also emphasizes the importance of maintaining good security practices, caching data for improved performance, and versioning APIs to manage changes effectively.

Reason for Selection: This resource was chosen because it directly aligns with the course material, providing a comprehensive guide to REST API design principles. The clarity of the content and its relevance to common challenges in API development makes it a valuable reference for anyone involved in creating robust APIs.

Comments on Content: The guidelines presented in the resource offer practical insights into building effective REST APIs. The emphasis on using JSON for data exchange aligns with industry standards, ensuring compatibility across various technologies. The recommendation to avoid verbs in endpoint paths simplifies API readability and adheres to the RESTful principles of using HTTP methods for actions. The article’s discussion on error handling and status codes enhances the overall robustness of API implementations.

Personal Reflection: As a developer, this resource reinforced the importance of consistency and adherence to best practices in API design. The concept of logical nesting for related resources provides a structured approach that can enhance both API usability and maintainability. Learning about caching strategies and the significance of versioning in API development has broadened my understanding of how to address performance and compatibility concerns in real-world scenarios.

Application in Future Practice: The insights gained from this resource will significantly influence my future API development projects. I plan to implement the recommended practices, especially in areas like error handling, security, and versioning. Additionally, the emphasis on caching strategies will be integrated to optimize data retrieval and enhance the overall performance of the APIs I develop.

In conclusion, the resource serves as a valuable guide for both beginners and experienced developers, offering practical tips for designing REST APIs that stand the test of time. By incorporating these best practices, developers can create APIs that not only meet current requirements but also adapt seamlessly to future changes in technology and user needs.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.