https://blog.restcase.com/top-5-rest-api-design-problems/

For this week, I wanted to stay on topic of REST APIs because I was still working with REST APIs this week. Also, I just think REST APIs are a fun topic for me to learn about since it’s so foreign to me. Anyway, in the blog post by Guy Levin from a blog that focuses on “Architecture, Programming, Ideas and Thoughts about microservices, APIs, cloud technologies and more” linked above, he writes about the top 5 REST API design problems. The 5 problems consist of: Using body in GET requests, usage of wrong or lengthy names for parameters, defining own error code and error message, ignoring caching, and returning too much data and long response times.

To summarize the 5 problems,
Using body in GET requests: add parameters inside the body, instead of in a URL. Many servers might not even look at the body of the request when it comes to GET method.

Usage of wrong or lengthy names for parameters: Since the URI already should state what is the resource, like project, there is no need for a long name like project_id, but only id.

Defining own error code and error message: Don’t use the approach of returning a response code 200 when something went wrong, make use of standard HTTP error codes.

Ignoring caching: Try not to ignore caching and use it, caching is very useful and gives several advantages like saving network bandwidth since this the server does not return content body but relies on the browser for that.

Returning too much data and long response times: Nobody wants to call an API and get a response after 2 minutes. Start designing your REST APIs with support for pagination, sorting and filtering.

I thought the problems Levin listed were simple mistakes that he wrote about to emphasize that these are easily missed. These problems seem to come up often if he has to write about them. I picked this blog because I thought it would be more complex problems but I think the blog post was a good post to reinforce REST API fundamentals. Looking back at these problems, I don’t think I really encountered much of these problems when I was working with the backend of the pantry API. Other than caching, all of these problems I didn’t encounter which I thought was good since the pantry backend was my first encounter with REST API stuff so I was already exposed to good fundamentals.

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

Traditional web applications function by having single pages that need to be refreshed when data has to be updated or submitted. You can likely recall using a website where each time a form was submitted or a link was clicked, you had to wait for the data to process and a few seconds later a new page appears. This process feels very cumbersome and discourages the use of the service.

Modern-day web applications are single-page, meaning data is dynamically added and removed from the HTML without the page needing to be redownloaded. To do this, a virtual dom is created through javascript and rendered as HTML to the page. When the virtual dom has a change, the actual dom is updated only in the area that is needed, without reloading everything. This change in design improves speed, reduces the amount of data to load, and improves user experience. Most services used online today are single-page applications and when they are not, it feels old and outdated.

There are three main web frameworks that are used to create single-page applications and these are React.js, Angular, and Vue.js. Of these frameworks, Vue has the fastest-growing developer userbase. A main benefit of Vue is that it is an easy-to-learn framework. In Vue, the virtual dom has a two-way data binding. To dynamically control the webpage, Vue uses user-created components that are linked together in a hierarchy. Each component is abstracted and allowed to have variables passed to it to make it display specific data. This feature allows custom HTML components to be reused, reducing repeated code and unmanageably long HTML files. A benefit to Vue components is that they can be easily unit tested, as only a small portion of the web application will be tested at a time.

In each component, it can contain state variables, which are like javascript variables that are tied to an element on the webpage. When a state variable is changed, its value is updated on the webpage. The process of watching a variable for a state change and updating the virtual dom then rendering the update to the webpage is called data-binding. This process happens nearly instantaneously and is what makes using Vue-built applications feel seamless and snappy.

I have used React.js in the past and I am familiar with the structure of combining html and javascript together. I am interested in learning more about Vue and what benefits this framework has to offer. Vue separates out the style, structure, and logic of each component which forces developers to keep their code cleaner than in React.

Source: https://www.altexsoft.com/blog/engineering/pros-and-cons-of-vue-js

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

Before constructing a project, we must picture out an image out or possibly draw it out to get a better grasp. This way tends to make a smother software as writing our code. But overtime we must face challenges along the way, which regards to maintaining software and keeping it maintained and readable. I have found this website which is called https://flylib.com/books/en/4.444.1.47/1/. This website is a library is all types of information regarding a library of books in different areas such as SQL, programming languages, interfaces, etc. I believe this website can aid me and any other developer to get a wider insight on the information they desire to seek. 

Design smells are basically violations regarding poor designing and that can be spread among other parts of one’s code and/or project. Which is why we have types of code smells to determine on how to seek and resolve it before it becomes an issue. The design smells are divided into seven principals.

Rigidity design is where you make a small change in your code could make huge, unexpected changes in other areas of the software. Fragility design is almost like rigidity, but this is where is when you alter a change in your code and broken code starts to erupt in. this is a sneaky design smell because we do not realize it sometimes and it can potentially make it through the production phase. Immobility design is common due to the fact of parts that are deemed useful are also harder to separate as it can pose a risk. Viscosity designs are also common when deciding between a not good choice that is convenient other than a good one that is not convenient. Needless design comes in two forms which are needless complexity and needless repetition. Needless complexity is straight forward of making your code overly complicated than it needs to be that consists of redundancy. Needless repetition is composed of unnecessary repetition. For example, when we make copies of classes to do the same thing and adding more classes on top which result in a developer’s laziness. Lastly, we have opacity design where readability becomes harder to read and takes time to understand the code which waste time on a developer. 

After gathering information on design smells and seen examples of each type of design smell in my CS-343 class. I understand that it is crucial to refactor code where it can stay readable and keeping it maintained. When starting a project, we always want to make a visual image to make it easier to implement. Also applying the rules and avoiding design smell as much as we can but sometimes, we can miss them and are able to determine the type of smell and find a solution. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Throughout this semester, the most interesting topics to me are those relating to how to produce good code. While I like learning about and implementing API requests in either the frontend or backend, regulating code utilizing something like the SOLID principles is interesting to me because it can be applied in many different situations and programming languages. We discussed the SOLID principles earlier in the semester, and while I walked to discuss them on this blog, I never got a chance to.

The Single Responsibility Principle states that a class should only have one job. The below article uses the example of shapes, namely a square and a circle. The Square class has the length of a square, and the Circle class has the radius of a circle. Another class, AreaCalculator, contains the logic that deals solely with adding the area of the different shape objects.

The Open-Closed Principle states that “Objects or entities should be open for extension but closed for modification”. If a programmer would like to take an existing class and add functionality to it, the existing class should be developed in such a way as to allow easy inheritance, and the programmer should add his implementation in an inherited class. In the article’s example, the author adds an area() function in the shape classes to calculate each shape’s respective area, then changes the design to implement a shape interface, which is implemented by the shape classes. The AreaCalculator then checks the instances of Shape Interface, and calculates that way.

The Liskov Substitution Principle states that every child class should be substitutable for their parent class. This means that a child class acts in the same way as its parent class, in this case, providing similar functionality and returning in a similar format. The article uses the example of a class called VolumeCalculator, that inherits from AreaCalculator. Both VolumeCalculator and AreaCalculator must be consistent, such that its implementation is the same.

The Interface Segregation Principle states that a client should never be forced to implement an interface that it doesn’t use, or depend on methods they don’t use. Building on the author’s example, if we needed to calculate the volume of a sphere, a class shouldn’t manage both a circle and a sphere, but segregate them into two different classes.

The Dependency Inversion Principle states that “entities must depend on abstractions, not on concretions”. In the author’s example, one class connects to the database, whereas another class depends on the connection class, thus they cannot decouple. Instead, we should implement a class using an interface, which is the parent class of the connection class. Abstraction is now applicable in both high-level and low-level classes.

Going through this article has been informative. I would also like to practice implementation and classes in Java or C++ to gain a better understanding of these principles.

Link:

1. https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

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

Hello Everyone! Hope all of you are doing well and Goodluck with your finals as we are in the last week of the semester. Today in this blog I want to talk about technical debt, it may sound like a financial term, but in the case of software development, technical debt is the idea that certain necessary work gets during the development of a software project in order to hit a deliverable or deadline. Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. It is basically the extra coding work that a software development company has to do because they took a shortcut route to finish and deliver the product in time without making sure if it works properly or not.

Is technical debt bad? The simple answer is it’s neither good nor bad, it’s debt. Several software companies today are under pressure from the market and competitive forces to develop and ship fast. Startups especially feel this “ship or sink” pressure. This need for speed leads many product and software development teams to make the tradeoff between taking on technical debt or launching later. There is sometimes unintentional technical debt with various software development teams such as the team who follows Poor practices, this leads the works done during the project to be messy which then makes the teamwork on it later which lead to technical debt, Software development teams being Inexperience with new coding techniques leads to the delay of the coding process or in some cases making the code messy which than later lead to technical debt. For example, a design approach that ends up containing many errors is unintentional technical debt. This sometimes occurs as the direct result of poor communication with the organization or misalignment between the developers and operations teams.

I choose this article because this article gives a very easy definition of technical debt and it also contains a video that explains technical debt in detail, this article also talks about what are the good reasons for technical debt and the bad reason for technical debt which makes the concept clearer. And having a major in Software development, it is important to know about the concept of technical debt as it will help in the future as a software developer.

Article: https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/#

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

This is a brief video detailing “PubSub“, also known as a Publish-Subscribe pattern in software architecture. This is an extremely common pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be.

A better way to visualize and understand this concept is displayed in the video. Alex Young codes a simple “clicker” style game in JavaScript where you get a certain amount of “xp” that fill up a progress bar per second. You can increase this gain by clicking a button that adds xp. Once your progress bar fills up, you move on to the next level and the progress bar resets. The way that PubSub fits into this is by publishing an xp_changed event and having the game’s User Interface subscribe to that event in order to update the progress bar and update the current xp. He also publishes when he “levels up” so that the game can recognize that it needs to reset the progress bar and progress the player on to the next level.

This application of a PubSub pattern was especially helpful for me in understanding a practical way to use an extremely popular pattern and also allow me to visualize how I might use it in the future. Coding in JavaScript is something I’m rather unfamiliar with but this video does a good job of describing the process in simple terms and showing how each change affects the game.

I chose this particular video because in the video I detailed in my previous blog post, the author spoke in depth on PubSub patterns and how prevalent they were in Software Architecture. I wanted to learn more about how they work and practical basic uses that I may encounter so I found a brief video showing a concrete example of how PubSub functions in JavaScript.

One thing that I found was particularly enlightening was actually in the comments of this video. Another viewer compared PubSub in JavaScript to event listeners in Vue. Since we were recently learning about Vue, I was able to use my understanding of Vue to better understand the examples in JavaScript.

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

Rest, an acronym for Representational State Transfer, is a type of API for web services that have a client-server architecture where clients request for data and servers return data in plain text formats, such as JSON, XML, and YAML. In my software engineering course, designing Rest API requests was the most difficult challenge I faced because I did not understand the parts of a request and their purposes. Because understanding a request’s components is fundamental to designing Rest APIs, the goal of this post is to explore the parts of a request. To help me achieve my goal, I will be using the article, “Rest API: the basics,” which explains the three components of a request: its method, uniform resource locator (URL), and body.

The request method is a procedure a client wants to make. The available methods include GET, PUT, POST, and DELETE. Because they are the same methods used by computers to download pages (or hypertext documents) from a web server, they are called Hypertext Transfer Protocol (HTTP) methods. The GET method is used to get one or more items from a server; the PUT method is used to update an item in a server; the POST method is used to create and add an item to a server; the DELETE method is used to remove an item from a server. Given the methods, a client can make requests to only create, read, update, or delete data.

The URL is an address to a resource, a unit of an item, in a server. The URL is made up of an endpoint and path. The endpoint is a reference to a web server, whereas the path is the identifier of the resource in the server. Given the URL, “https://twitter.com/justinbieber,” the endpoint is “https://twitter.com/,” and the path is “/justinbieber.” The endpoint is the reference to Twitter’s server and the path is the identifier of Bieber’s Twitter page.

The body is an optional section where a client specifies the data it wants to send to a server. It is only used with POST and PUT methods because the server would need data to update (put) or create (post) items. The format of the body must be in the format of the response. In other words, if the server returns items in JSON format, the client must input data in JSON format.

To bring my understanding full circle, I will be breaking down and interpreting the components of a request I defined and called for a food pantry software in my course.  The request is

“GET http://localhost:10001/orders/61b16887ca02e000073ceabc.” I used the GET method because the request is intended to retrieve all orders of a given ID from an Orders database. “http://localhost:10001,” is the reference to my webserver, which I hosted on my local computer. “/orders/61b16887ca02e000073ceabc,” is the identifier for specific type of order in the database.  The components make up the request to fetch all orders of a given ID.

https://towardsdatascience.com/rest-api-the-basics-d91859537c9d

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

For this week’s post, I am refining my definition of an API and exploring the reasons why an API might be used. When I was learning to program in Java in CS140, the course textbook described the Java API as a library of prewritten code programmers can use to add functionality to their programs. Because the textbook described an API as a library, I defined APIs as libraries of reusable code. When CS343 reintroduced me to APIs, my instructor described an API as a link between two applications. Because his definition of API conflicts with my definition of API, I feel as though my knowledge about APIs is unsound. To polish my understanding, my post’s goal is to explore APIs and the reasons they are used. To help me achieve my goal, I will be reflecting and adding to MuleSoft’s article, “What is an API? (Application Programmable Interface)”

An API is how two applications can share information. To explain an API, Mulesoft uses an analogy; Mulesoft states, in a restaurant system, a waiter is an API for a customer and the kitchen. In other words, the waiter is how a customer can communicate his or her order to the kitchen. Mulesoft then transitions to APIs in software development by introducing flight search applications, such as Priceline, Kayak, and Expedia. The flight search applications aggregate information from various airlines, including Worcester Regional Airport and Boston Logan International Airport, by using APIs. In other words, flight search applications collect flight information from airline applications through an API. Both examples show that APIs are used to share data.

While Mulesoft explores only one reason why developers use APIs, developers use APIs to also

hide complexity. Ride-sharing applications, such as Uber and Lyft, are examples of how APIs are used to hide complexity. They use the Google Maps API to display a map and generate routes for drivers and riders. I know they use the Google Maps API because after installing Uber or Lyft, the application asks for permission to use Google Maps. The API hides complexity because Uber and Lyft developers do not need to create a map and define pathing algorithms. Uber and Lyft show that developers can focus on building upon the capabilities of another application by hiding complexity.

A third reason why developers use APIs is to extend functionality. Online stores that accept Paypal payments, such as BestBuy, eBay, and Etsy, are examples of how APIs are used to extend functionality. They use Paypal’s API to provide a Paypal login form and collect money. The API gives online stores the ability to accept Paypal payments. By adding functionality, end-users will have multiple payment options.

Returning to the conflict that inspired this post, the Java API is a library and an API. It is a library because it provides reusable code. It is an API because it allows two programs to communicate with one another. The library is simply part of the API.

https://www.mulesoft.com/resources/api/what-is-an-api

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

I decided to review a topic previously discussed during our second homework assignment this semester in Software Design and Architecture; Design Patterns. This is a much shorter video that serves as more of a refresher of five different design patterns and their main uses, advantages, and disadvantages.

Software design patterns are described as a general, reusable solution to a commonly occurring problem within a given context in software design. This is far too general to be applicable in any meaningful way. What this video provides is much needed context for what each pattern is and in what context would it be useful.

The author of this video is named Jack Herrington and he works for Nike as a Principal Software Engineer. He has written six books and is a verified authority on Software Design. The first pattern that Herrington describes is the Singleton pattern. The Singleton pattern is described as a pattern that restricts the instantiation of a class to one “single” instance. Herrington says that this pattern is very good for use in a database driver or, if you’re over on the client, the data store with the current state of the application. The pro of this pattern is that you can go and get to that data whenever you want, you just have to get the singleton and away you go. The con is that it’s very difficult to back out of a singleton pattern and that it can be very restrictive.

The second pattern discussed is the Facade pattern; this pattern is an object that serves as a front-facing interface masking more complex underlying or structural code. This can improve readability but may also mask some functionality, thus requiring the consumer to do a bit of work to access the feature that they want. Third is the Adapter pattern; which allows the interface of an existing class to be used as another interface. Herrington uses his camera as an example, how the body of the camera serves one main purpose and is then modified by the interchangeable lens. The main draw of this is that it can be applied to almost any app and allows for additional functionalities, only limited by the “body” of the app. The pitfall is that many developers overuse this pattern and complicate too much of the app, thus damaging the quality.

These were the first three and I highly recommend you watch the video to learn more about each of them. I plan to take this knowledge with me and keep an eye out in my career for different uses of each of them and try to better understand why each pattern is used in professional settings and what each of them accomplish differently.

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