Applications such as Expedia, Amazon, Netflix or Facebook are using an API that facilitates the sharing data from one application to another. There are hundreds of APIs for many fields like finance, social network, payments and e-commerce. Nowadays, the fastest-growing category APIs is sharing and analyzing of data across various applications which is a place the characteristics of the API determine the value of the application or deem it untenable for use in the real world. But how could APIs connect each application together, let’s us take a deep dive into the world of APIs.

API stand for Application Programming Interface which includes three important components

• Procedures: Known as routine which refer to the specific tasks or functions a program performs. For example: Facebook provides a search API for developers to examine data for analytical purpose
• Protocols: The format is used to communicate data between applications. However application might not have the same format
• Tools: Simply put – building blocks which is the recipe to construct new program

APIs are needed to bring applications together to perform a designed function which allows to use, share and execute data. APIs act as middle man, this allows developers to build new functions between applications and businesses use on a daily basis.

How APIs actually work?

Application: Enterprise businesses and corporation rely onto user financial data, inventory levels and purchase order confirmation back and forth between suppliers, customers and partners. Consumers and business depend on mobile application, spending much time per day on smartphone and tablet apps to exchange businesses with partner and customers.

Programming: Application relies on programming. The application does not make itself. In other words, we would not be able to make new application without developers who write the code to create, testing and design the application software and user interface.

Interface: This is where users and application interact with each other

API is important that without it we would not be able to order stuff from Amazon or personalize your favorite Google homepage. The simple way to understand APIs is to understand that API is an interface that let this application talk to another inside the application via commands designed by programmers.

Types of APIs

• Rest APIs: known as RESTful APIs, stands for Representational State Transfer. It has grown in popularity of late, as an essential part of Web Services. It’s designed for developers to perform requests and receive responses via HTTP. There are four types of HTTP commands that REST is based on which are GET, PUT, POST, and DELETE. Instagram uses API for users to pull up information and pictures
• SOAP APIs: Stands for Simple Object Access Protocol. SOAP is a protocol that is defined by a standard. It is dependent on XML-based systems and programming, has larger and more expensive data. Despite the disadvantages, SOAP provides better security for users.
• RPC APIs: Remote Procedure Call was the earliest form of APIs. They are designed to execute the block of code on different servers.

APIs are running data for business every day. They give businesses and users the flexibility to increase productivity and improve security. Taking advantage of APIs can help them have innovative approaches. While the potential is undeniable, efficiency is still another matter.

Source:

https://www.cleo.com/blog/knowledge-base-what-is-an-api

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

Whenever you interact with a program it is usually done through an API. Every website you visit, most programs you use, even your own operating system uses APIs to communicate with application. APIs are very prominent in modern computing and are essential to establishing the connection between programs and users alike.

Seeing as every programmer will interact with an API at some point or another, it is important to understand their place and how to create a good API should you need to do so. It is important to realize that characteristics such as being easy to work with, complete, and concise must be met when creating an API. Doing so can result in many gains not just in the finished product, but in other aspects of coding projects. Keshav Vasudevan put it, good API design can lead to “improved developer experience, faster documentation, and higher adoption for your API.

As the author puts it, an API must be extremely simple to use while achieving its goals. To that end Vasudevan has outlined key aspects of API design that one should take into account when creating an API. Much of it comes down to proper organization and the use of consistency to avoid confusion while utilizing the API. Small changes such as keeping URLs short and simple along with setting up resource functionality with HTTP methods can make the process much easier. Methods such as GET, POST, PUT, PATCH, AND DELETE are commonly used in these APIs along with many other methods commonly used in HTTP.

Along with proper organization while building the API, it is just as important to ensure that it is not indecipherable by others. A problem that often occurs with developers and product owners is that the developers might the meaning of a feature and implement incorrect functionality. Developers should check that all GET commands needed are implemented and have an example where one can expect a specific output on a successful run. It is important to give and receive feedback for the developers due to the disconnect that can occur between the target audience of a program and the developers creating it.

An example of the GET response as follows:

responses:
200:
description: Successfully returned information about users
schema:
type: array
items:
type: object
properties:
username:
type: “string”
example: “kesh92”
created_time:
type: “dateTime”
example: “2010-01-12T05:23:19+0000”

Once all this is done, it is important to remember that complexity should be handled ‘elegantly’ as Vasudevan puts it. This entails that there are likely large amounts of different data and information that must be accessed. A lot of these are common and it makes no sense from an efficiency standpoint to create a resource for each piece of data, therefore it is important to keep the ability of resources broad. You should keep the retrieval process simple, down to a query and parameters when searching or using a resource. Overall the API must be as user friendly as possible to ensure that it works well with future users who don’t know the API like you.

Bibliography

Vasudevan, Keshav. “Best Practices in API Design.” SmartBear.com, https://swagger.io/blog/api-design/api-design-best-practices/.

https://swagger.io/blog/api-design/api-design-best-practices/

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Blog Discovery

As a newcomer to the software industry, Kubernetes was foreign to me. This is also an article on the K8s, so please indulge me.

Applications: developers who provide a predefined service to stakeholders, Docker is a well-known runtime environment for building and building applications in containers. Creating a sample Go app; let’s create a basic Go app that we’ll use to deploy to our minikube cluster.

Kubernetes: The Kubernetes Engineering Manager is an open source container management and deployment platform. It orchestrates the clusters of virtual machines and schedules the containers to run on those virtual machines based on their available compute resources and the resource requirements of the container.

What are Pods?

A Kubernetes pod is a group of one or more containers, linked together for the purpose of Nodes and clusters: workstation that provides resources to developers a node can be thought of as the workstation that provides these resources and Kubernetes, the manager that allocates these positions to employees. In Kubernetes, a node is a working computer that can be virtual or physical. A node can have many pods, and Kubernetes automatically manages the scheduling of pods among the nodes in the cluster.

Deployment: the team’s objectives and structure defined at the start of the year a deployment provides declarative updates for Pods and ReplicaSets. In a deployment, we set a desired state and the deployment controller gradually converts the current state to the desired state. Take a look at the deployment file below deployment. The above deployment file is like a declarative template for Pods and Replicas.

The above deployment named myapp in {metadata.name}, creates a replica set to display two pods of myapp.

What are ReplicaSets?

Creating a K8s deployment kubectl apply -f deploy. Kubernetes Services: The SPOC team that routes relevant external communications to developer pods are ephemeral resources. In Kubernetes, a service is an abstraction that defines a logical set of pods and a policy for accessing them. Kubernetes services provide addresses through which associated pods can be accessed. Create a Kubernetes service kubectl apply -f service. The minikube tunnel command can be used to expose LoadBalancer services. The Minikube tunnel runs as a process on the host and creates a network route to the cluster CIDR service using the cluster IP address as a gateway. You can now use this IP address to open the service in the browser. The section on services is incomplete without an analogy with the life of developers. Imagine an external team uncertain or confused about the use of a feature developed by the development team. With that, we come to the end of the article on K8s and the Adventures of the Freshest Day One.

https://betterprogramming.pub/relating-with-docker-and-kubernetes-as-developers-an-analogue-5e662b1f817b

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Microservice Architecture is a strategy for designing software in which each part of software exists separately from the others in what is called a microservice. These microservices have their own CPU’s, exist in their own runtime environment, and are designed to do one specific job. Microservices communicate with each other through Application Program Interfaces (APIs) to form the whole of the product.

In their blog “What Is Microservice Architecture? Microservices Explained”, Johnathan Johnson and Laura Schiff discuss in detail the difference between Microservice Architecture and Monolith Architecture, a system in which the entire application exists as a single unit, and how Microservice Architecture is implemented and used. Today I want to discuss the pro’s and con’s of this architecture listed in the blog, and how I plan on using it in the future. I selected this post specifically because it goes into detail about the benefits and drawbacks of Microservice Architecture. If you would like to learn more about the specifics of the implementation, please visit the blog post linked above.

There are many pro’s to using microservices. The main reason it is implemented is because it promotes feature independence. This feature independence has many benefits, such as developer independence, isolation, resilience, and scalability. Personally I think that developer independence is the most beneficial since developers will become very competent with their microservice and will be experts at their specific job.

When a microservice wants to interact with another it makes a call to that service’s API. Since microservices exist in their own runtime environment they will continue to function even if that API call is not executed. This means that if a part of an application goes down the rest of the program continues to run, albeit at a loss of functionality. In my opinion this is the one of the best reasons to use microservices since it makes applications very resilient.

The final pro I would like to discuss is scalability. Since each service has its own dedicated CPU, its usage can be scaled to meet demand. I think this is a great byproduct of microservices, but do not believe this should be the main reason for using them.

The issues related to microservices are real, but manageable. Microservice Architecture adds complexity to a project, but this can be mitigated with training. Microservices also cost more since they use more processing power and require experienced engineers, but I believe the benefits are worth the cost. Finally microservices adds a security risk since each microservice can be attacked individually. Given an experienced team of engineers and good oversight, this risk can be lessened.

In conclusion, I believe Microservice Architecture to be a very good design choice and plan on using it in my future work. Reading the blog post was worth the few minutes it took, and I can say that I understand microservices much better now than I had before. The benefits far outweigh the risks and I can imagine many employers would already be using this architecture.

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

Semantic Versioning 2.0.0, SemVer for short, is a format widely used by developers to determine version numbers. When implementing Semantic Versioning, you will need to declare an API (Application Programming Interface). This is because the way the version number is incremented depends on the changes made against the previous API. A semantic version consists of 3 numbers separated by decimals and is formatted like so: MAJOR.MINOR.PATCH. There are rules to follow when incrementing each of the numbers and the SemVer documentation provides a very helpful summary of when to do so:

MAJOR version is incremented when API incompatible changes have been made.

MINOR version is incremented when backwards compatible functionality has been added.

PATCH version is incremented when backwards compatible bug fixes have been made.

Next let’s take a look at each version number specifically. I came across this blog post on the Web Dev Simplified Blog and it does a good job of explaining each of the versions further. 

MAJOR Version 

The major version number is only to be incremented when any API breaking change has been introduced. The blog provides examples and a major change could be as simple as an entire library rewrite or a rework of a single component that still breaks the API. The version MUST be incremented if any backwards incompatible changes have been made. It is possible that minor and patch level changes have been made as well, but they must be reset to 0 when the major version is incremented. For example, when a major change is made to version 1.17.4, the new version number will be 2.0.0.

MINOR Version

The minor version number is incremented when backwards compatible changes have been made that don’t break the API. According to the SemVer documentation, it MUST be incremented if any public API functionality is marked as deprecated and MAY be incremented if substantial new functionality or improvements are introduced within the private code. When incrementing the minor version number, the patch level must be reset to 0 as well. For example, when a minor change is made to version 1.14.5, the new version number will be 1.15.0.

PATCH Version

The patch version number is incremented simply when backwards compatible bug fixes have been introduced. This number is commonly updated, and the only change that should be made is the fixing of incorrect behavior. For example, a bug fix for version 0.4.3, would make the new version 0.4.4.

Hopefully this blog was helpful in understanding Semantic Versioning. It is evident of its wide usage that Semantic Versioning is a useful tool to use when creating new versions. For the most part, the process of deciding the version number is straightforward, but it is neat to see that there is an actual guideline that many developers follow.

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

Though most people may not consider this an issue during the early stages of learning how to use Docker for deployment, data retention and persistence is one of the problems that one needs to consider when they need to utilize Docker containers. Previously, I wrote about virtualization using either Virtual Machines and Docker, though I mostly focused on how both essentially work on an operating system and what they require regarding system resources. What I did not mention, however, was how either Virtual Machines or Docker operate when it comes to data persistence. We are aware that the host systems that we use retain the data that we create between sessions. This means that if I power the computer that I am using now off and then on after submitting this blog post, the majority of the data that was created in the previous session will be available in the next session. However, as we begin to work with virtualization, this  issue of data persistence becomes a much greater issue for us to consider when working with Docker. In the case of virtual machines, data persistence is not much of an issue.

Data persistence for Docker containers, however, works differently. It is stated in the Docker documentation that:

The data doesn’t persist when that container no longer exists, and it can be difficult to get the data out of the container if another process needs it.

https://docs.docker.com/storage/

When a container is stopped and then restarted, whatever files that were created and used in the container will be deleted and the container will essentially run on a “clean state”. However, there is a way to guarantee data persistence on a docker container at any point through binding mounts or volumes to the container. Though Docker offers other types of binds, such as tmpfs mounts and named pipes, I will mostly be focusing on bind mounts and volumes for the remained of this post as ways of maintaining data persistence between a host machine and a Docker container.

While I was researching for more information regarding the differences between using bind mounts and volumes, I came across the following two articles, one tutorial titled Docker Volumes – Tutorial on buildVirtual.Net and one article titled Guide to Docker Volumes on Baeldung.Com by Ashley Frieze. In the Baeldung article, Frieze showcases how the Docker file system works and, in turn, how data retention is affected in a Docker container before explaining the differences between using volumes and bind mounts. Likewise, the buildVirtual tutorial also outlines the above differences, as well as showing how to utilize and delete volumes through docker commands.

Although both bind mounts and volumes can be used for data persistence, it is important to know which method to utilize depending on where we want the binds to be stored in the host system or how other docker or non-docker processes may need to interact with the specific data.

Direct link to the resources referenced in the post: https://www.baeldung.com/ops/docker-volumes and https://buildvirtual.net/amp/docker-volumes-tutorial/

Recommended materials/resources reviewed related to Docker mount and volumes:
1) https://4sysops.com/archives/introduction-to-docker-bind-mounts-and-volumes/
2) https://medium.com/@BeNitinAgarwal/docker-containers-filesystem-demystified-b6ed8112a04a
3) https://www.baeldung.com/ops/docker-container-filesystem
4) https://digitalvarys.com/docker-volume-vs-bind-mounts-vs-tmpfs-mount/
5) https://medium.com/devops-dudes/docker-volumes-and-bind-mounts-2fb4bd9df09d
6) https://docs.microsoft.com/en-us/visualstudio/docker/tutorials/use-bind-mounts
7) https://blog.logrocket.com/docker-volumes-vs-bind-mounts/

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Hello, I want to write this blog after finishing my exam like an hour ago; I am looking over some class activities and see any questions to review, but something that sometimes confused me. I read the word “docker-compose” in some class-work exercises; I got interested and looked it up again. I found two links that helped me understand what Docker Compose does and how you use Docker Compose?.

Docker Compose: Run multiple containers as a single service or extend many different Docker containers midway. Even an essential tool for any application that needs various micro-services, as it allows each service to be in a separately managed container easily.

What Does Docker Compose Do?

Docker containers are running applications in an isolated environment. Its application deployments are arranged in Docker for the benefit. However, it’s often complex as running a single container. Usually, Many containers come together to act as one service made up of many changing parts.

Running all deployment time is disordered, so Docker provides Docker Compose; it runs multiple containers to clean it up. It helps all arrangements in one YAML file and starts all the containers with one 

command.

Rather than having all services in one big container, Docker Compose allows to split them up into individually manageable containers. This is better for building and deployment, and it can manage all of them in separate codebases and doesn’t need to start each container manually.

Using Docker Compose is a three-step process:

• Build the part images using their Dockerfiles, or pull them from a registry.
• Set all of the component services in a docker-compose.yml file.
• Run all of them together using the docker-compose CLI.

Docker Compose still builds and publishes Docker containers using a Dockerfile. But, instead of running them directly, it can use Docker Compose to manage the configuration of a multi-container deployment.

How Do You Use Docker Compose?

The form for a docker-compose file is done in docker-compose.yml. It doesn’t need to place this at the root of a project like a Dockerfile. It can go anywhere as it doesn’t depend on any other code. However, it builds the images locally and will need to go into a project folder with the produced code.

A Compose configuration file that runs a WordPress instance using the WordPress container off the Docker Hub. However, this depends on a MySQL database, which Composes also creates.

• First, a version number since the arrangement can change depending on which version.
• Next, A list of Services. 
• Lastly, the volumes are stored.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello, I want to write this blog after finishing my exam like an hour ago; I am looking over some class activities and see any questions to review, but something that sometimes confused me. I read the word “docker-compose” in some class-work exercises; I got interested and looked it up again. I found two links that helped me understand what Docker Compose does and how you use Docker Compose?.

Docker Compose: Run multiple containers as a single service or extend many different Docker containers midway. Even an essential tool for any application that needs various micro-services, as it allows each service to be in a separately managed container easily.

What Does Docker Compose Do?

Docker containers are running applications in an isolated environment. Its application deployments are arranged in Docker for the benefit. However, it’s often complex as running a single container. Usually, Many containers come together to act as one service made up of many changing parts.

Running all deployment time is disordered, so Docker provides Docker Compose; it runs multiple containers to clean it up. It helps all arrangements in one YAML file and starts all the containers with one 

command.

Rather than having all services in one big container, Docker Compose allows to split them up into individually manageable containers. This is better for building and deployment, and it can manage all of them in separate codebases and doesn’t need to start each container manually.

Using Docker Compose is a three-step process:

• Build the part images using their Dockerfiles, or pull them from a registry.
• Set all of the component services in a docker-compose.yml file.
• Run all of them together using the docker-compose CLI.

Docker Compose still builds and publishes Docker containers using a Dockerfile. But, instead of running them directly, it can use Docker Compose to manage the configuration of a multi-container deployment.

How Do You Use Docker Compose?

The form for a docker-compose file is done in docker-compose.yml. It doesn’t need to place this at the root of a project like a Dockerfile. It can go anywhere as it doesn’t depend on any other code. However, it builds the images locally and will need to go into a project folder with the produced code.

A Compose configuration file that runs a WordPress instance using the WordPress container off the Docker Hub. However, this depends on a MySQL database, which Composes also creates.

• First, a version number since the arrangement can change depending on which version.
• Next, A list of Services. 
• Lastly, the volumes are stored.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.