This week I have chosen to continue to write about API’s and specifically the differences in all the API’s out there as REST shouldn’t be the only type of protocol used and learning more about the different kinds of API’s used will be a great boost in the future. I have chosen a blogpost that I think goes over these different kinds of API’s well enough for someone to start learning about the different kinds of API’s

In summary, Castellani goes over the main types of API,s which are Open API’s, Partner API’s, Internal API’s, and Composite API’s. An Open API is also called a public API in which it is publicly available to developers and user without much restrictions. The focus of this API is on the outside external users for third party services/data. A partner API is an API that is only given access to specific business partners and are used for outward communication outside the company. An internal API is also called a private API has many restrictions and is only worked on by the internal development teams. A composite API is a combination of multiple API’s and services. Castellani also goes over different protocols such as SOAP which stands for simple access object protocol which came before REST. It was the first to bring standardization in how to manage service using network services but was seen as too strict. There is also RPC protocol which stands for remote procedural call protocol which is the oldest out the three given. This protocol is hard to maintain and update and was used for client code execution.

This blogpost has given new bits of information on the different kinds of API’s out there. The way we have changed from the different rules and protocols to what we mainly use today. The previous versions were restrictive in their own ways and eventually were let go for what we have today. I wonder if eventually we will let go of REST and create a new set of rules to follow. There might be some situations where a certain protocol would be preferred over the over but people just mainly go for REST which is what we are working with in our API’s. There is also the parts on the different types of API’s and the one I have worked on is perhaps and open API and would like to see on how something like a composite API would look like to work with and handle.

Source: https://blog.axway.com/amplify-products/api-management/different-types-apis

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

This week will be continued talk on APIs and specifically I wanted to learn more about the structure of our API’s including on the differences between frontend and backend and any extra information on API’s that can be included. I have chosen a website that goes over what exactly these are and gives a good amount of information that could be useful later down in our careers.

In summary, frontend and backend are two very popular terms in web development. The term frontend is usually used for the part of the website that the user directly interacts with like the GUI’s. This is also called the “client side” of the application and use languages that should sound familiar to you such as HTML, CSS, and JavaScript with JavaScript being the most popular language of them all. This is because of several advantages such as flexibility, speed, and extended functionality although it does have some disadvantages in areas such as with debugging. Now if the frontend is what the user interacts with, the the backend should be everything that is kept out of sight from the user such as work with the databases, the scripting, and the API itself while making sure it can connect to the frontend. The languages used include python, PHP, and java all being widely used. The work on the frontend and backend has also become quite specialized over the years in which it is usual for one person to either work with just the frontend or just the backend and people who work on both are called full stack developers.

This resource has given me insight on the work we are doing with the API’s and with the work we are doing on the backend. The work that we are doing with the databases and the API’s is an entirely different area from the frontend that we haven’t even touched yet. The areas that have to be learned are numerous that require different sets of skills and talents to work in. It makes me wonder on whether we will get to work with the frontend in this class or in a future class. The I should prepare myself a bit more if one would want to become a full stack web developer seeing the needed skills in both ends. Although I haven’t done much work on any frontend material so I would have to wait to see on what the experience is like when working on the frontend on deciding if I should focus on one or another in the future.

Source:https://www.interviewbit.com/blog/difference-between-frontend-and-backend/

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

As we continue to work with API’s, I have decided to dedicate this blogpost to talk about security with API’s as eventually we will have to take this into consideration when we go into more in depth with them in the future. Security will always stay priority in which I think it would be helpful to look at this area now. I have chosen a blog post that gives us some good practices we can look at to help better our API’s.

In summary, this authors first goes over TLS which stands for Transport layer security which is a cryptographic protocol used to help prevent tampering and eavesdropping by encrypting messages sent to and from the server. The absence of TLS means that third parties get easy access to private information from users. TLS can be found when the website URL contains https and not just http such as the very website you are reading from now. Then they go over Oauth2 which is a general framework and use that with single sign-on providers. This helps manage third party applications access and usage of data on the behalf of the user. This is used in situations such as granting access to photos to used in a different application. They go in depth over codes and authentication tokens with Oauth2. Then they go over API keys where we should set the permissions on those and don’t mismanage those. They say at the end to just use good, reliable libraries that you can put most of the work and responsibility onto so that we can can minimize the mistakes we can make.

These practices will help bolster my knowledge on the security placed within the API’s we are working with. This blogpost has helped me learn more on the general framework on what security measures are placed in the general API landscape. TLS looks to be a standard protocol used in 99% of websites you see but also makes me wonder on all of the websites that I have traversed through that didn’t have TLS and you should too and make sure that you have no private information in danger on those sites. This also makes me wonder on how TLS is implemented such as with the LibrePantry API that is being worked on if it is being used there(hopefully). Then perhaps when we work further in the API’s, we get to see the security practices implemented.

Source: https://stackoverflow.blog/2021/10/06/best-practices-for-authentication-and-authorization-for-rest-apis/

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

Throughout the semester, we talked about microservices here and there and went over them in several activities and look to continue working with them in the coming weeks. This blogpost will be dedicated to them and their architecture. I have chosen an article written by Alyssa Walker that takes what we have already seen in previous activities and takes them into a greater level of analysis than previously looked at and also includes information about SOA I had not known about. This I deemed good enough to write a blog post about.

In summary of what I have read from the article, microservices is a type of architecture pattern in which services are provided to other parts from applications. Alyssa goes into monolithic architecture and compares the two in detail with a focus on the cons of monolithic architecture and pros of microservices. Microservices have several advantages such as with the start of time and the allocation of resources in different sectors is much easier to manage than with monolithic. The separation of the services make it much easier to work on making changes to the program in cases of faults in which availability will be there unlike in monolithic. She also includes talking about service oriented architecture in general and how microservices are an implementation of SOA.

This article has taught me several things about the different kinds of architecture we have and some reasons for why we are using microservices instead of monolithic in our activities. Microservices also seem to be a relatively newish idea, coming to fruition somewhere in the 2000s, which makes sense as how the computing world changed quite rapidly during the past few decades and how docker is a tool used for microservices. The advantages are quite useful to us such as with team members as we are not exactly a large team working on this project in which a larger team would be needed for a monolithic style project. Also considering the nature of this project and how it is being helped developed by students, there are probably going to be numerous faults that need to be fixed in which microservices would benefit better due to its separated services. It also makes me wonder of the issues that would arise in our food pantry program if we were to use monolithic architecture instead. This information in general will help me understand our work down the line as we work on the LibreFoodPantry program eventually and in the future as we develop into our careers and work with microservices in other places.

Source: https://www.guru99.com/microservices-tutorial.html

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

Last week we went over docker and some general information about it. Now this week we have started to go over REST APIs in our activity’s so I decided to dedicate this weeks blogpost to it. The Source I have chosen is a fairly recent article written by Zell Liew that is lengthy and gives us some general insight on what REST APIs are and should be a good read to many who are looking to learn.

A REST API is firstly, an application programming interface(API) which allows the programs to communicate with each other and this API follows REST. REST stands for Representational State Transfer which is basically another set of rules/constraints that the API has to follow when being created. Here with REST APIs, we are able to request and get data back as a response. Zell goes over the 4 makings of a request which firstly the endpoint which is the URL we request for. The endpoint itself is made of the root-endpoint which looks something like https://api.website.com. Then there is the path which helps us finalize what we are requesting and query parameters. Then we have the method as the 2nd part which is what sort of request do we actually send which are in 5 types: get, put, post, patch, and delete which are then used to determine the action to take. Then there is the 3rd part which the the header which actually has a number of uses but they in general provide information in one way or another. Lastly, there is the data/body which contains the information we are sending to the server. Zell also goes over some more about authentication, https code, etc.

Zell’s explanation over REST APIs is a good start on helping me understand on what APIs are and their actual use in computer science. This view on how websites work is also quite interesting. This also will help in class as we potentially work with APIs further in our class activities and make the process a bit more fluid. The prevalence of REST APIs is very much apparent with it being used by big company sites like Google and Amazon and with the rise of the cloud over the years has led to increased usage of REST APIs. This information of REST APIs is a must if I am to continue to improve and potentially work in a career that has to work in areas like this as it looks like REST APIs will continue to be used for a while longer since people are comfortable with it so I should too.

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

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

For this week’s blog post, I have decided to go over into more detail on docker since we have been setting up and working on docker for the last few weeks and I wanted to learn more about it. The source I have chosen seems to have a good amount of information about Docker that I can utilize the source is reputable. Here I have learned more on the general landscape of what docker is and its place in the digital world.

In this article that I have chosen, IBM goes over Docker with how Docker is an open source containerization platform that enables users to package and run code much more efficiently than other platforms. It is widely popular at over 11 million different developers using docker and you can find it mentioned anywhere container is mentioned on the internet. Docker while wasn’t the first to utilize container technologies, it did it in a revolutionary way in which it made the process us creating and utilizing these containers simpler, less resource intensive and more flexible allowing the developer to to more easily run their applications. Docker also provides portability where you are able to take packaged software and run it on other platforms and systems. There also isn’t the need for individual OS’s and other resources for each application that you want to run but instead they can all run on the same OS. The benefits are numerous and this has allowed Docker to explode in popularity over the years since 2013 and looks to keep on rising. The article also goes over some Docker terms and tools although there was a Kubernetes section which is now outdated since Kubernetes deprecated Docker.

This source had brought insight in what place docker had in the world and how it would affect me later on. I can see from the website that Docker seems to be continuously growing and will be a part of our coding lives for an extended period of time. The benefits are quite astounding considering it is also free to use in which any extra information on Docker will help down the line when we work on it more. It also makes me wonder on if Docker will stay on top forever. The growth has been continuous but it won’t stay like that maybe in a decade since we are always innovating further. There was that point where Kubernetes is mentioned to help with larger complex container environments in which Docker could potentially adapt in the future to help with these environments or perhaps might become outdated in the future. There is always the chance for competition to rise to go against Docker, perhaps by a bigger company like google.

Source: https://www.ibm.com/cloud/learn/docker#toc-how-contai-5UTUfWRp

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