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.

REST APIs have become increasingly popular over the last few years, and for good reason. REST has less of a learning curve than other API models, has a smaller footprint, and parsing of JSON is less intensive than traditional XML parsing. There are a few key standards to REST, including utilizing certain requests like GET, POST, PUT, and DELETE, for example.

When a call is made using REST API, there are a few things that go on within the call itself. First are the endpoints, which is a unique URL that is used to represent objects or groups of objects of data. Every API request has its own endpoint. In addition, there are also the methods used for the request. These include those I listed above, like GET, POST, and PUT. A header contains the information that represents the metadata associated with the REST API request. The header also indicates the format of the request and the response, and provides information about the status of the request. Lastly, the request also consists of data, which is also referred to as the body, that is usually used with the POST and PUT commands and contains the information that will be updated or created.

Another important part of REST APIs are parameters. When someone is sending a REST API request, they can use parameters to narrow or further specify their search request. These are valuable tools, since it allows you to filter the data being received in a response. Some parameter types include path, header, cookie, and the most common, query. Query parameters are located at the end of a URL path and can either be required or optional. This can be useful if, for example, you are using a base GET command to get all of the objects in the database, and you can have an optional parameter to specify which of all those objects you want, using something like ID or name, depending on your implementation.

Source

I chose the above source because it gave good additional information on REST APIs, compared to other websites I visited. This helped me further understand how REST APIs differ from other web APIs, and what helps make REST different and usually better. REST APIs definitely have their many uses, and allows ease of use with their standards of requests, using easy to understand methods like GET, POST, and PUT, to name a few.

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.