Category Archives: CS-343

Pros and Cons of Java REST API Frameworks

Link to blog: https://dzone.com/articles/java-rest-api-frameworks-1

In class, we’ve been covering REST APIs and how to use certain call methods such as GET, POST, PUT, and DELETE. Before class, I had heard of REST APIs but never had any understanding of what they were, or how to interact with them. I figured I would dive deeper into other Java REST APIs. The article Java REST API Frameworks by Farith Jose Heras García lists some REST APIs along with their advantages and disadvantages.

García begins with a simple introduction to Java REST APIs and what they do, specifically how they enable communication between applications and other software, and make the passing of data easier. Each API on the list includes pros and cons, and then a CRUD (create, read, update, and delete) example using the API. 

First on the list is the wildly popular Spring Boot. According to García, some of the benefits of Spring Boot are that it is easy to use and set up, has a lot of built-in support, and has a large library of plugins and modules. The cons are that beginners might struggle to understand it, and it might be too much for smaller projects and better for larger projects instead.

Second on the list is Jersey. Jersey is simple, ideal for microservices, and also has a decent-sized library. However, García considers it slow and difficult to debug.

Third on the list is Play Framework. It’s lightweight and flexible, high performance, and also offers a library of plugins. It’s updated and designed for modern Java applications, as it works with Java 8 and Scala. Unfortunately, it has a tough learning curve and debugging can be a challenge.

The final on the list is Vert.x. It is lightweight, flexible, and has high-performance, and also supports JavaScript. The cons are that it is difficult to debug and might be hard to understand for a first-time user.

I selected this resource because it is an article that is a good reference for an updated list of Java REST APIs currently in use. It gets the point across for each item, whilst being a short enough read to be a good refresher for those unfamiliar with the information. It’s mainly beneficial for choosing which REST API to use with your project or application.

I found this to be a solid article for learning a little bit about Java REST APIs and how to choose them. For example, I did not know that Spring Boot is too heavy for smaller applications. The formatting was simple, and it’s pretty interesting to see the frameworks in action with the CRUD code examples García provided. Choosing the right REST API framework for your project’s needs is very important since many factors can go into such a decision (size, libraries, and easy learning curve). I hope to apply this to projects of my own and perhaps jobs where REST APIs are needed.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Blog #4: Software Frameworks

As I become a more knowledgeable developer, I hear the term ‘software framework’ being used more frequently. In my research, I’ve seen an increased interest in frameworks such as Angular and React. To understand what these are, I must first define what is a software framework.

In the article What is a Framework? Software Frameworks Definition, written by Joel Olawanle, walks through a general definition of software frameworks, comments on how they may be applied, and how they differ. Olawanle defines a framework as such, “…is a structure that you can use to build software. It acts as a foundation so you don’t have to deal with creating unnecessary extra logic from scratch.”(Olawanle). Supposing a framework is implemented correctly, developers will save time allowing them to start the project earlier. Additionally, the foundation it provides will not be prone to human error. If the components of a framework are implemented from scratch, then there could be errors that would be much more difficult to fix further in development. Since frameworks can be modified, there is less of a reason to implement their functionality from scratch.

Olawanle expands his definition to other aspects of software development. Before reading this article, I understood that there were both frontend and backend frameworks, but I was surprised to learn that mobile applications and data sciences have their respective frameworks. While reading Olawanle’s article, I noticed a framework I used a few years ago, that being Bootstrap. This qualifies as a software framework as it gathers files needed for a functioning website (.html, . css, and .js) into one structure. This allows the developer to easily make their website without having to build this structure. Angular and React both are classified as Frontend frameworks. Both of these are used for creating interfaces for websites, but each has its unique components. React can use JavaScript to create HTML and CSS files, meanwhile Angular has dependency injection allowing it to more freely communicate with other applications. Each of these creates a specialized purpose for the framework. 

Depending on where a developer is working (front end, back end, etc), there will be a framework that can create a strong foundation for their code. Before selecting their framework, the developer must weigh the tradeoffs between the various frameworks and consider which would support their project principles the most. Using a framework in this scenario would save time and reduce any human error manually implementing these components introduce. In my experience with Theas’ Pantry, the backend does not use any framework listed within Olawanle’s article. After reviewing the documentation, it seems as if the back end would not support these listed frameworks as they are not directly language-compatible. This means more time and resources would be invested into implementing the framework, than potentially implementing components of such individually. Frameworks provide a strong starting point for development teams, depending on the design choices frameworks may be incompatible with certain projects.

Link to Article:

https://www.freecodecamp.org/news/what-is-a-framework-software-frameworks-definition/

-AG

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

Blog #3: Software Documentation

Communication with those who help construct it or those who will use it is an essential component of any project. Software documentation serves both these ends, as it informs anyone approaching the project of topics such as the requirements used to run said software, instructions, and myriad other facets of the project. Documentation is created for those interested in the specified software/project. The Swimm Team, in their article What is Software Documentation? Types, tools, and best practices, list two types of documentation. These are external and internal documentation.

External documentation seeks to explain all aspects of the software that are not locally accessed. Most of this documentation involves user interaction. This is seen through End-User documentation, which provides the user with instructions on using the software, or through Just-In-Time Documentation, which guides the user while the program executes. A more technical piece of documentation, API documentation, is also considered external. Although most users may not directly interact with the API, this type of documentation is targeted towards developers who may want to expand the API functionality or use it in their projects. Due to the accessibility of external functions, its documentation must be equally accessible to its audience. A level of abstraction must be provided to reach this goal, as uninformed users do not need to understand how the internal systems of the software function, but rather they must learn how to interact with it.

Internal documentation refers to everything ‘behind the scenes’ so to speak. Contrary to external documentation, this documentation is less accessible, meaning it can go into detail on how the systems of the specified software work. Due to this complexity, it serves as a great introduction to the project and can be used to onboard new developers. Internal documentation ranges from information regarding the development cycle of the software, as seen through scheduling documentation,  to design choices seen throughout, which can be found in Software design documents. During the development process, software engineers can refer to internal documentation to ensure their contributions follow the team’s vision for the software.

My experience with software documentation has been limited up until this year. My most recent experience with documentation was through the HFOSS project Theas’ Pantry. Within this project, there was API documentation, available through a .yaml file, which listed all functions and associated code with all API calls. Additionally, there was indirect documentation offered through activities introducing onboarding developers onto the project. Each of these activities introduced a broad topic, such as software architecture, which then transitioned into how it’s applied to Theas’ Pantry. This untraditional form of documentation allows the onboarding developer to interact with the components in a microcosm before they apply their knowledge on the project. Documentation is a vital component of software development. Without supporting texts such as this, clients interested in the project would be met with inaccessibility, and onboarding (in addition to current) developers may not understand the project as a whole which could jeopardize the production of such. 

Link to Article:

https://swimm.io/learn/software-documentation/what-is-software-documentation-types-tools-and-best-practices

-AG

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

Documentation

I chose the blog post, “Software Documentation Best Practices” by David Oragui because it addresses the challenges in documentation and how to go about following the best practices. The blog shows us all of the best practices of documenting your work to prevent having challenges when faced with the task. In my time coding, documenting has been a struggle knowing how to document and when to do it. This is what led me to choose this blog post, so I can learn how to not make these mistakes in the future and become better when it comes to creating documentation.

The blog explained to the reader how software documentation is essential for enhancing user experience and ensuring consistent software development. Despite its benefits, developers often neglect documentation due to constraints like time, expertise, or resources. This gap can result in user difficulties and inefficiencies in development processes. The blog first described the  types of software documentation. First, project documentation which is aimed at development teams, covering technical design, project plans, and requirements. Next is product documentation, this is more user-focused, including instructional manuals, reference guides, and installation instructions. Third, the blog described process documentation which details steps for development, testing, and maintenance, ensuring consistency and clarity. Then, technical documentation which provides in-depth technical insights, such as APIs, architecture, and data models. In addition, there is system documentation which explains system architecture, components, and troubleshooting methods. Last is user documentation, this is similar to product documentation as it is user-friendly materials like how-to guides, tutorials, and reference docs. The benefits of documentation include improved user experience, enhanced collaboration, increased efficiency and improved quality. The best practices for writing documentation include prioritizing documentation, identifying the target audience, defining the scope, developing a strategy and being able to write clearly for the audience.

From the blog, I was able to rethink my use of documentation and highlighted the best practice when creating documentation. Going forward, I plan to be more thoughtful about my use of documentation and how I go about creating it. The blog taught me that well-designed documentation should cover all the necessary information to allow others to understand without being confusing.. This perspective will help me develop documentation that is easily readable and documents what work is being created. After reading, I feel like I will be able to not make as many mistakes when it comes to creating documentation.

https://helpjuice.com/blog/software-documentation

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Implementing New REST API Calls

APIs are integral to building scalable and flexible applications. They allow communication between clients and servers using HTTP methods such as GET, POST, PATCH, and DELETE. Adding new endpoints to your REST API can improve functionality, meet user requirements and support new features. To understand new endpoints, take an example if you need a GET/ inventory endpoint to retrieve the current stock levels and a PATCH/ inventory endpoint to update the stock based on things like adding or removing items. Some steps to implement a new endpoint include plan the endpoint. This starts by defining the endpoint’s purpose, required input, and expected output. For example, Endpoint: GET /inventory, Purpose: Retrieve total inventory in pounds, Response: JSON object with the current inventory count. Another step is to test the endpoint where you write test cases to verify the endpoint works as expected. Documenting the endpoint is important because this is where you use tools like swagger to document your API and you include details like input, response codes. Another important topic about rest API calls is error handling. It is essential for any API to provide meaningful feedback to users and developers while maintaining a secure system. Best practice is to use HTTP status codes effectively. For example, 400 Bad requests for issues like missing parameters or invalid input, 404 not found for requests to nonexistent resources, 500 internal server error for unexpected server issues.

When building REST APIs, adhering to strong design principles is important to creating scalable, maintainable, and user-friendly interfaces. There are three principles that include resource-oriented design, HTTP method semantics and consistency. For resource-oriented design REST APIs treat resources as primary entities representing objects in the application domain. For example /users to represent user data, /orders to represent order records, /products to represent items available for purchase. Another principle is HTTP method semantics. Each HTTP method has a specific purpose and using them correctly is critical. For example, GET fetches data and retrieves a list of users. GET/users/{id} gets the details of a specific user. POST creates a new resource for example POST/users creates a new user. PUT updates an entire resource for example PUT/users/{id} replaces all data for the user with the specified ID. DELETE removes data for example DELETE/users/{id} deletes the specified user. All this is to say that using HTTP methods correctly simplifies the developer experience by creating a predictable pattern. I chose this resource because it talks about API as an entirety, it lists the pros and cons, principles of rest APIs, shows examples of how they work.

References.

https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

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

Software Architecture Patterns

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.

Week-13 Post

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.

AMD’s rumor trying to enter Smartphone SoC’s market

CS-343, CS@Worcester

In recent news AMD is rumored to be entering the smartphone processor market. Many people assume that Samsung and AMD’s partnership is a sign of entering the smartphone processor market. I read in articles that AMD is attempting to incorporate RDNA 2 into smartphone SoCs. These SoCs are for Samsung phones. 

First let me explain what RDNA 2 is. It is a gpu chip made for the RX 6000 series of gpu. RDNA 2 was mainly used for gaming. It handles more extreme demand from video game frames. It also tries to be as efficient with power. 

Let me give some more details on why these rumors are possible. In recent years AMD has been incorporating RDNA 2 into handheld gaming devices and consoles like the PS5. While making the chip efficient for small devices, they had to make sure the chip was smaller. They also needed to make sure it did not demand as much power from these smaller devices. Normally chip makers would only make their gpu chips for desktops and laptops. Chip manufacturers enabled desktop GPUs to work in a laptop with limited power. They did this by lowering the GPU power draw and reducing the performance by a percent. 

While AMD was capable of figuring out how to make RDNA 2 chips within restrictions of laptops. They faced a few difficulties. Nevertheless, they managed to make their RDNA 2 chips suitable for even small devices. Now here is a problem. Unlike handhelds, you only have a limited amount of space available for fitting components in phones. Also, you need to consider that consumers want their cell phone battery to last more than 24 hours. They also do not want the phone to be bulky when using it. Lastly, consumers want their devices to be high quality. They expect better performance. They want the devices to take good photos and record video at an even higher quality than last year’s models. 

If AMD can figure out these constraints of making smartphone SoC’s, I hope they create more changes in that market. Imagine not just Apple, Samsung and Qualcomm and more are competing in that highly competitive market. If we want the best products, we need a lot of competition in the market. This competition will constantly improve products. It also protects consumers from companies selling inferior products.

Work Cited:

Thitu, Naftary. “AMD Rumored to Make Entry in the Smartphone Market.” Techweez, 22 Nov. 2024, techweez.com/2024/11/22/amd-rumored-to-make-entry-in-the-smartphone-market/.

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

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Best Practices for REST API Design.

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.