My experience with APIs outside of classwork is very limited, so I wanted to take this opportunity to further familiarize myself with them. After a discussion in class, I am especially eager to learn more about REST APIs and how they might differ from other APIs. Jamie Juviler’s “REST APIs: How They Work and What You Need to Know” is a very good start.

Introduced in 2000 by Roy Fielding, REST APIs are application programming interfaces that follow REST guidelines. REST, which stands for representational state transfer, enables software to be able to communicate over the internet in a way that is scalable and easily integrated. According to Juviler, “when a client requests a resource using a REST API, the server transfers back the current state of the resource in a standardized representation.” REST APIs are a popular solution for many web apps. They are able to handle a wide variety of requests and data, easy to scale, and simple to build as they utilize web technologies that already exist.

REST guidelines offer APIs increased functionality. Juviler states that in order for an API to properly take advantage of REST’s functionality, it must abide by a set of rules: client-server separation, uniform interface, stateless, layered system, cacheable, and code on demand. Client-server separation addresses the way a client communicates with a server. A client sends the server a request, and the server sends that client a response. Communication cannot happen in the other direction; a server cannot send a request nor can a client send a response. Uniform interface addresses the formatting of requests and responses. This standardized the formatting and makes it easier for servers and softwares to talk to each other. Stateless requires calls made with a REST API to be stateless. Each request to the server is dealt with completely independent of other requests. This eases the use of the server’s memory. Layered system states that, regardless of the possible existence of intermediate servers, messages between the client and main server should have the same format and method of processing. Cacheable requires that a server’s response to a client include information about if and for how long the response can be cached. Code on demand is an optional rule. It allows a server to send code as part of a response so that the client can run it.

I picked this source because I thought the information was valuable. Again, I have very limited experience with APIs, even less with REST APIs, and I struggled somewhat to understand them. Jamie Juliver provides a very thorough yet easily understood overview of REST APIs. I was not aware that what sets a REST API apart from a regular API was its adherence to a set of rules. This article helped me better understand REST APIs, and I am eager to put this knowledge to use in future coursework and projects.

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

This is a topic that I have been wanting for a while to write about but never really got around to doing so until now. For this week, I am going to review a post made by Martin Fowler. In the first part of the blog post, Mr. Fowler explains what the acronym stands for and where the term comes from. Mr. Fowler than walks the reader through an example of when we could apply YAGNI. In the blog post, the example that he uses is a company having two teams work on two different components of a program (one for sales and the other one for pricing). The pricing team then predicts that in six months’ time, they will need to create software that handles pricing for piracy risks and Mr. Fowler argues that this violates the principle of YAGNI. He argues that because the team is making assumptions based on something that has not happened yet, the feature the team builds might be wrong or worse not needed or used at all. In which case, this will mean that the team wasted a lot of time, energy, and effort analyzing programming and testing something that may or may be useless. In the amount of time the team spent developing the precaution for piracy, they could have used that time working on a different required feature of the program. Furthermore, the feature they build could handle the problem incorrectly which means they might have to refactor this feature later down the line. It also adds an extra layer of complexity to the program and adds more items for the team to repair and maintain. In addition, Mr. Fowler argues this is a bad habit for people to get into. The habit of making precautions in advance because it is impossible to predict all possible outcomes and as he put it even if we tried, we would still end up getting “blindsided”.

I wanted to write about this topic now because when I was doing the intermediate assignment for Homework 4, I was thinking about how my approach was violating the single-responsibility principle because one of the methods was doing three different things. When realizing this, I started thinking about my other bad programming habits. One of which was I tended to think ahead and code things that I think the program would need and how it violates YAGNI. So, I decided to read and review a post on YAGNI because I wanted to learn more about why you shouldn’t code things in advance so that the next time that I code, I can avoid those mental pitfalls. I think reading about this blog post would help me a lot because sometimes I have a hard time making these realizations on my own unless someone brings it to my attention in discussion.

https://martinfowler.com/bliki/Yagni.html

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

When designing an API it is extremely important to get it right the first time. API calls are the backbone of you application, and without well designed endpoints your frontend will not be able to communicate with your backend effectively, if at all. If you do not design your API with forward thinking in mind, you may end up redesigning many of your endpoints and a good portion of your application as well. The good news is that API design is usually left to experienced developers; the bad news is that experienced developers still mess up from time to time.

Since designing a good API is so important, there are many standard practices which will help you with your design process. “REST API Best Practices – REST Endpoint Design Examples” is an article written by Kolade Chris which outlines nine best practices that you should keep in mind whenever you are designing an API.

To begin with the simple practices, it is important to use JSON format for sending and receiving data. Firstly this is a good practice because it is industry standard, but more importantly it is designed to be used with many of the most common frontend languages, such as JavaScript, PHP, and Python.

Practices two and three are similar since they both relate to naming convention; use nouns instead of verbs as endpoints, and name your collections plural. The reason you should use nouns as endpoints is because the verb part is contained in your HTTP request such as POST or GET, so you can do GET /items. The reason you should use plural collection names is to indicate that it is in fact a collection and not a single item.

The fourth practices Chris mentions is to follow industry standard status codes. This is very important, but also not difficult to do; simply look up standard status codes and follow those.

Practices five and six are also similar to each other; they both relate to narrowing your search. When designing an API, you should use nesting to indicate how things relate to each other, and you should also use filtering, sorting, and pagination to narrow down a request which returns multiple values. For example, if you wanted to find a specific blog post by title you could design your endpoint like this: https://blog-website.com/users/userId/posts?title=query. This indicates that the post exists within the user endpoint, and also queries based on title.

An easy but important practice is to use SSL with your endpoints. When using SSL you will have https// instead of http//. The increased security is definitely worth the expense you might need to pay.

The final two practices are the most important: use semantic versioning and provide adequate documentation. It is important to use versioning when designing an API so that users are not forced to use the most updated version, and it is important to provide documentation so that users know how to actually use the API.

Following these practices does not guarantee that your API will be designed well, but it does ensure that you won’t have basic problems with it.

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

During this semester we have started to use MongoDB. While I did get some general explanations of MongoDB in class, I felt like I needed to get a better grasping of how MongoDB works as a database and how I can better use it. Since MongoDB is a NoSQL styled database and my general understanding of databases comes only from using relational databases, I felt like an article helping to summarize and clarify NoSQL would be advantageous.

https://dev.to/lmolivera/everything-you-need-to-know-about-nosql-databases-3o3h

This article goes into great detail not only the advantages or features of NoSQL but the terminology used alongside with it. It has descriptions of multiple types, how they differ and what they are used for and including some helpful guides around designing these different types of databases.

More specifically my focus is on the type of NoSQL database that MongoDB is which is a document based database.

As the article describes, a document type database stores it’s data inside of a “document” that could contain varied types of data. Even to the point of storing documents nested inside of other documents. Which highlights the advantage of this type of database which is scalability. Being able to store nearly anything inside the database and not needing to force it’s formatting is a great feature. I’m trying to think of a scenario needed for nesting your entire database inside as an object containing your entire database. I don’t seem to be able to think of one in specific, but the concept is interesting to me and maybe it’ll be useful later.

This article also briefly goes into describing how JSON formatted NoSQL databases are structured. This was good to see as this is exactly what I have been using in class as well as in the most recent homework assignment.

It also gave a link to a list of databases who have used Document based NoSQL databases and was interested to see eBay listed their and specifically using the same database MongoDB as we are using in class.

https://www.edureka.co/blog/real-world-use-cases-of-mongodb/

Near the end of the article it begins to describe the CAP Theorem. The theorem as I learned from this article to be a general issue around picking which attribute we focus on for the service. Is it frequently consistent with reads/writes? Does every request have the most recent changes? Does it still perform it’s functions when some of the machines are currently not connected? This concept details that you must pick only two and generally partition tolerance is chosen first as one of the two. The reasoning being that as a service being able to provide it regardless of a particular aspect of the database going down you still want to be able to provide a service.

Overall this article gave me some good general insight on what a NoSQL database specifically is and how it is generally used and will help me in class when referring to the database we have been using MongoDB.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

In last week’s blog, I covered docker compose files and their significance. For today’s blog, I would like to go in depth on docker-files to explain how they are structured. To give a quick review of what Docker Compose is. Docker Compose is a tool that allows developers to create and run multi-container docker applications. Once again, I am referring to The Definitive Guide to Docker compose, posted by Gabriel Tanner. He does a good job of breaking down the structure of a docker-compose.yml file.

Docker Compose File Structure

By using a docker file, you can list the containers you want and all of the specifications as you would in a docker run command. As explained in last weeks blog, almost every docker-compose file should include the following:

• The version of the compose file
• The services which will be built
• All used volumes
• The networks which connect the different services

Docker files are structured upon indentation. Consider the idea of levels of abstraction.

On the top levels are the version, services, and volumes tag. The next level down is where the containers are listed, then parameter tags such as image, volumes, and ports. And finally on the lowest level, the respective rules for each parameter.

Here is a simple docker-compose.yml file:

Let’s take a look at each tag individually.

Version:

The version tag is used to specify the version of our compose file, based on the Docker engine we are using. For example, if we are using Docker engine release 19.03 or later:

Services:

The service tag acts as a parent tag, as all of the containers are listed underneath it.

Base Image/Build:

The image tag is where you would define the base image of each container. You can define a build using preexisting images available on DockerHub. In this case, we are defining a web1 container using the nginx:mainline image. 

You can even define the base image by pointing to a custom Dockerfile:

Volumes:

The volumes tag allows you to designate a directory where the persisting data of a container is managed. Here is an example of a normal volume being specified.

Another way of defining a volume is through path mapping, linking a directory on the host machine to a container destination separated by a : operator.

Ports:

Specifying a port allows you to expose your host machine to the container that is running. In this case, we are defining port 10000 for the host port and we want to expose it to port 80.

Those are all of the main components that you need to structure a Docker Compose file. In this blog post, I simply covered the basic tags and structure. Compose files allow you to manage multiple containers and specify properties to a finer detail. There are tags that I haven’t covered such as dependencies, commands, and environment that Gabriel explains really well. 

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

After doing more work with activities 13 and 15 and working on homework 4, I wanted to read more about how to use the http methods with REST API calls because I was having some trouble understanding how to implement them in the homework at first and wanted to get a better grasp on how they work to set up my endpoints and paths.

I have decent understanding of each of the methods and how they correlate with the paths and endpoints we have been working with so far. The main source I used for reading more about the methods was the REST API tutorial about http methods. It goes over each of the methods and gives a summary at the end which is a table. It also gives a brief glossary over some terms used and references to other sources. It gave good explanations for each method and was divided in evenly sized sections.

The main five methods used that we are familiar with are GET, PUT, POST, DELETE, and PATCH. GET is used to find and return an item or object based on the parameters we choose, like a name or ID. POST creates an object and posts it to the data. PUT updates and replaces data for an object. DELETE removes/deletes an item/object. PATCH is used for minor/partial updates. We have not used PATCH in our activities yet, but it did show up as a method in an example given for activity 12 for how http methods work with urls.

Going more into the methods, GET methods are considered safe methods because they do not make any changes to the data, and they are also idempotent because they are expected to allow multiple similar requests with the same results. The other methods all change the code or data in some way, so they are not considered safe. DELETE is the other idempotent method because the result of each DELETE is a removed object. PUTs and PATCHs seem the same because they both are used to make changes to existing data, but they differ how much they update. PATCHs are for smaller and partial updates, while PUTs are for bigger updates and usually involve replacing existing data.

After this reading and doing more work with REST API, I have a better idea on how to implement them in code and continue with the activities and homework.

https://restfulapi.net/http-methods/

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

https://www.vogella.com/tutorials/JavaConcurrency/article.html

This article discusses the use of Concurrency in Java. As defined in the article Concurrency is “the ability to run several programs or parts of a program in parallel”. Concurrency is meant to cut down on time and make a program or programs more effective and easier to use together. The article describes how Java uses several threads to “parallel process” or behave asynchronously which ultimately makes the application run faster and smoother. Concurrency is all about the performance gain in the application, this gain can be calculated using “Amdahls Law” which tells you the maximum performance gain.

According to the article a Java program runs its processes in one thread (by default) through javas “Thread Code” which is also capable of allowing multiple threads through the Thread class. Through threads you use the synchronize keyword in order to define which methods or code should be executed by one single thread. The synchronized keyword provides specific sections of code with a “lock” and any code protected by this lock will be executed by one thread instead of multiple. The memory of threads communicates with the memory of the application through the “java memory model” which also allows the thread memory to refresh itself with the main memory.

I chose this article as it goes into depth about the subject of Concurrency and helps students like myself understand what exactly concurrency is and what the purpose or use of concurrency is. Concurrency is a complex subject as it involves the thread class which isnt commonly used by beginners in java and it involves new keywords not previously learned. The article goes into detail about threads and what exactly they do/why they are important and it also tells you the exact purpose of concurrency which is program efficiency i.e. speed, correctness, etc.

I actually learned quite a bit from this article. I already knew the general idea/concept of concurrency and what it is but as far as the more in depth information which was provided like threads, synchronize and volatile I never knew exactly what each part was and what they each entailed. This article was organized very well and provides the reader with the necessary information in order to learn about and work with concurrency in their own code. Overall the article was very helpful and I would recommend it to other students as it explains the subject very well.

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

These weeks, I’ve been learning about APIs and back-ends. I also had the opportunity to practice with an API in my current homework. However, I am very confused about the relationship between API and back-end. I don’t understand how the API is related to the back-end, what the API and back-end are used for.

To answer those questions, I tried to search for some information about API and back-end. Back-end API development introduction, written by Cesare Ferrari, is a resource that I have found useful. The website has clear definitions of back-end and API; and their relationship is also described in detail, which helps me get better understanding of the two new terms. From the website, I know that back-end is a service that will send data to the front-end which interacts with the end users. On the other hand, API, Application Programing Interface, is a set of definitions and protocols for building and integrating application software. API can be also considered a back-end component, which is typically used by front-end applications to communicate with back-end applications. In other words, the API is used to outline all the requirements or functions that will interact with the end user. The back-end will rely on the API to create endpoints that fulfill all the requirements designed in the API. There are different types of APIs, but the REST APIs, which stands for Representational State Transfer, is one of the most popular. It communicates via HTTP requests to perform four basic functions known as CRUD. These are creating data (post), reading data (get), updating data (put), and deleting data (delete).

Moreover, the website also provides a general information of Node.js and Express to explain more how to create and use back-end applications. Node.js is used to execute a Javascript on the back-end without the browser. Express is a library or a Node.js application is used to create and send HTTP requests.

All in all, I think the website is a good resource because it’s short, concise, and provides the essential information I need. It gives me a general idea of what the back-end and API are, and how the back-end and API relate to each other. By understanding the two new definitions, I was also able to understand what I was supposed to do in each one. Based on what I read from the site and what I did with my API homework, I can envision the API as an interface class and the back-end as my concrete class that will implement all abstract methods from the interface class.

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