Now that we, hopefully, have a decent basis of knowledge about REST and REST API’s we can finally begin discussing the specifics on implementing a REST API. I am afraid that, once again, I will run out of space before being able to cover all of the aspects of REST API creation so I encourage any readers to check the source I am referencing for this post. My source is a pretty well laid out tutorial that has a step by step guide on each part of this process. This is what I have been doing most recently in my coursework so it is nice to finally reach some directly relevant information. Granted much of the surrounding code was already done for us, so some of this will be brand new to me, but we have been designing some endpoints. All of that aside, let’s just jump right into it.

Well actually one more quick note before we begin, this tutorial is using Docker, which you can read about in one of my earlier posts. Additionally there are some parts of this web application that are already completed, so you can download this to follow along with the tutorial if you want. This example is just a database for a generic company with employee information, created with javascript. I am not going to go too deep into detail about creating all of these files to make the web application, as that is an entirely different topic. The first thing to note when implementing a REST API is an acronym, CRUD. Essentially this means that your API should create, retrieve, update, and delete. The equivalent methods to these are post for create, get for retrieve, put or patch for update, and delete for delete believe it or not. One other important part of implementing a REST API is handling response codes. The codes that you may want to account for can vary for each function, for example a function that edits data will use response code 201. To do this you can add a section for request handling at the end of your openapi.yml file. Here you can specify specific messages to be returned by each HTTP response code that gives more specific feedback based on your web application. And I am afraid that is all I have space to discuss, once again coming up a bit short.

Well, as I said in my first post, I vastly underestimated the sheer amount of information there was about REST API’s. I really tried my best to give some information about them, but there is still so much more that simply could not fit into these three blog posts. I would definitely try to follow along with a tutorial implementing a REST API either with docker or flask, as I saw both when researching this post. Regardless I found this information helpful and I hope any readers did too.

Source

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

As was promised last week, I return for the second REST API post.Please try to contain your excitement. All jokes aside this topic has been pretty interesting to learn about, and perhaps a bit more complicated than I initially assumed. For this week I will be discussing the remainder of the post I discussed last class, and another I found containing more specific information about REST API’s. Specifically this post will discuss resources, resource methods, and some other important concepts, such as endpoints. Additionally I will discuss a part of the REST API tutorial website discussing a comparison between REST and HTTP, as they do appear to be similar in function and appearance to some extent.

First up for discussion are resources and their methods. Luckily this is significantly more straightforward than the previously discussed topics. As stated on the REST API tutorial website, as always all links will be posted at the end of the post. Resources are any piece of information that can be named. Some examples provided are a document, image, or collection of other resources. Essentially a resource is an identifier for some component that is interacting with another. As for resource methods, these are your GET, PUT, POST, and DELETE methods. One common misconception about these that this site discusses is that one of the authors of the HTTP specification stated that there is no set way to implement them. These methods should also be listed in the API response for the resources they are altering. Finally these methods should instead be used to create application state transitions based on the clients selections. I feel like all of this could use a summary. Essentially resources, data, and resources methods, methods that alter data in some way, should be kept together to improve readability for your client. Additionally the manner in which the methods are implemented should be tied into what exactly your client wants. We are almost ready to discuss how to use REST API’s, but there is just a bit more setup first.

I found another blog post by a frontend developer who goes over a few more important aspects of REST. I am unfortunately running out of room in this post, so I am only going to focus on discussing two things, requests and endpoints. A request is a URL that consists of four components, being an endpoint, method, headers, and data. These requests are how you grab and modify data, which is returned back as a response. As for endpoints, they are the URL you requested. It is the link used to access the endpoint within the REST API itself. For example, if you had a REST API that saved and stored data of customers from a grocery store, you may have an endpoint like www.grocery.data.com/customers/viewdata. I am short on space so this closer will be brief, but my next post will be the last in this REST trilogy.

Sources

https://restfulapi.net/

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

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

 Next in my apparent series of explaining computer science topics so I am not completely lost in class is Rest APIs. In all seriousness we have been working with REST APIs as of late in class and I do actually find this blog to be an effective way of sitting down and grappling with these topics. Thus for this week I decided to do the same thing, being explaining exactly what REST API’s are. To do this I will be using a REST API tutorial website and blog post by a front-end developer. As I looked into these more however, I realized that this topic would be a bit too complex for one blog post. For this one I chose to focus on the REST principles.

   Let’s not waste any time here and get right to a definition, because I am starting to lose it a little with all of these different terms. REST is an,”…architectural style for distributed hypermedia systems,”, according to the REST API Tutorial website. To put that in terms that make more sense to a simple man such as myself REST, an acronym for representational state transfer, is a set of principles that are followed to make loosely coupled web applications. More specifically, these constraints are uniform interface, client-server, stateless, cacheable, layered system, and optionally code on demand. These principles will be the majority of this post. I honestly did try to squeeze them into one part of a blog post but it just is not an effective way of explaining them, nor is it fun. 

   Uniform interface is the idea of applying generality to a components interface through some interface constraints. Client-server is that, by separating interface and data storage problems, you improve the portability of a user interface across multiple platforms, and have more simplified server components. Stateless stands for the idea that each client-server request is self contained; each has all required information to understand the request. Cacheable means that, for any response, a client cache has the right to reuse the response data for other similar requests. Layered system means that each system component cannot interact beyond the layer containing other components it needs to interact with. Finally there is code on demand, which is an optional principle revolving around allowing clients to extend program functionality by downloading scripts to be run.

   Phew…let’s all just take a deep breath and a step back to figure out what the purpose of all of this is. These REST principles all revolve around making a simpler, more flexible program for your client and developers. Essentially these principles are more complicated, or just different, forms of design smells. Unfortunately I am running out of space for this post, but in the next I plan on diving even further into this topic, but I will leave my source below in case you want a more developed explanation.

Source:

https://restfulapi.net/

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

For this next blog post I decided to finally sit down and learn exactly what front-end design entails. I know that it has to do with the parts of a program that your user is interacting with, but beyond this I have almost no knowledge. With a few projects on the horizon for me that will require some front-end work, I figured it was a great time to start learning. To begin I wanted to discuss a blog post by an experienced front-end developer, the first being Frontend Design by Brad Frost.

This blog post brings up some really interesting points about front-end developers that I had not really considered before. Before I begin I want to give an exact definition for front-end design. Essentially, front-end design is the practice of making HTML, CSS, or a JavaScript to produce an interface allowing your user to utilize a website or web application. So front-end design has much more to do with visual design than programming to an extent that surprised even myself. Brad Frost states it very clearly in his blog post, stating that a front-end developer will understand many general principles of app development, but do not necessarily focus on any in particular. For example you might understand a decent amount of JavaScript and some backend software, but cannot write application code nor engineer the backend software. As a front-end developer you are more of a jack of all trades and master of none. So front-end designers still work with programming, but these languages are different from more traditional ones.

Front-end designers do not necessarily need to be traditionally trained in programming to effectively do their job. This is because languages like HTML and CSS, while still certainly coding, do not involve some of the complexities of Java or Python. There is much more of a focus on making an attractive, effective design rather than ensuring you have optimized and debugged different facets of the design’s code. One issue that results in this, as stated in the blog, is that some just see front-end designers as capable of the same level of programming as dedicated developers which is not the case. The blog also mentions how developers and designers are often not kept together, creating a manufactured divide between the departments. This is a more general issue with some teams in the industry but, undoubtedly, adds to the confusion of exactly who does what. As I have now learned, front-end developers tend to have a general understanding of development principles, but focus on the UI design and usability.

Sources:

Frontend Design | Brad Frost

What Is a Front-End Developer? · Front-End Developer Handbook 2018 (frontendmasters.com)

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

For this blog post I chose to focus on something I have used multiple times but still did not fully understand, this being Angular. I have been using it only on my own personal project to build a web application, but have not actually sat down and researched what I was using. Thus for this blog post I will explore exactly what Angular is, and specify some situations where it could be useful to implement. To begin, I will try to define exactly what Angular is. 

Since, as stated, I do not have much knowledge about exactly what angular is, I found some other posts to reference. The first of which is Angular Introduction, written by an experienced programmer Ilya Bodrov-Krukowski. I would highly recommend checking out this blog post, as it goes far more in depth than I will be able to. From my relatively brief time with Angular, I assumed it was just a web application development and hosting platform, but the answer is not this simple. This initial assumption was not entirely wrong, just missing some parts. As stated in Angular Introduction, Angular is really more like a collection of tools that can be used to develop a web application and it defines how the app should be designed and organized. Essentially, Angular sort of guides you on exactly how to go about making the app, which would explain why I had a relatively easy time working with it. Some other important features Angular provides is data binding and dependency injection, both mentioned in Ilya Bodrov-Kurkowski’s blog post. Data binding essentially meant that you could see changed data in a view in real time and dependency injection, “allowed application components to be wired together in a way that facilitated reusable and testable code”(Angular Introduction). These are extremely useful, as databases are used on a variety of applications, and being able to reuse code is always helpful. But why should you use Angular?

To answer this I am going to discuss my own experience with it. Before this, I wanted to give the reasons listed by Agular’s own blog, Angular University. I do not want to spend too much time on this, as there are many visuals on this post that help put this into perspective, but Angular handles a lot of backend work that I never even knew about. Essentially a jQuery application is compared to an Angular application, and the jQuery app has much more code with fewer efficiencies. As always I will leave the links for each post below, but I would recommend just scrolling through this one to understand the difference. As for my own experience, Angular was surprisingly straightforward to use. After getting it installed, it is as simple as adding some html for your web app and some components, using JavaScript code, and inputting a few command prompt lines. If you are developing a web application, I would highly recommend considering this framework.

Links:

https://www.sitepoint.com/angular-introduction/

https://blog.angular-university.io/why-angular-angular-vs-jquery-a-beginner-friendly-explanation-on-the-advantages-of-angular-and-mvc/

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Despite the fact that I have been using docker containers for multiple weeks now, I still find the concept of docker containers to be a bit more mystical than I would like. Thus, I chose to try and find some good sources that break down this concept, which led me to a podcast on Spotify of all places. To begin however, I wanted to give a summary of what is stated on Docker’s own website. These containers are  called a standardized unit of software, sort of like a big zip file containing the program, relevant libraries, dependencies, etc.. This allows containers to be used across any system, as normally you would have to ensure that the systems utilizing your program have all relevant data before using your program. 

The podcast I found gives a more general overview of Docker as a whole and, if you are still a little hazy on exactly what it does, I would highly recommend giving it a listen. Essentially, docker containers are much faster than utilizing a virtual machine, as they do not require an entire image of an operating system to run on. Having used some virtual machines, such as VMWare, in the past, I can definitely confirm that Docker is significantly faster, and easier to install. You can also run multiple containers simultaneously that are all self contained. This could be useful for larger projects, as you could have one facet that has different dependencies or requirements, or maybe one is required to run in a different language than another. These containers are all “wrapped” into an image that will run these containers, but also has all of the other important information, as was listed above. These programs can be even further customized through creating your own docker file. This could allow you to specify, for example, one image to use node and java whereas you have another utilizing bash and python, and much more. 

To summarize, Docker containers essentially act as their own self contained systems, in a similar conceptual manner to a virtual machine. Its core function is to give each user their own environment to run certain software, but removing the issue of varying operating systems. The amount of containers you may want will vary, depending on the scope of your program. These containers are unique in that they are both more lightweight than a virtual machine and allow great consistency in terms of normalizing system to system deployment for users. Additionally, multiple containers can be combined into an image, which is a collection of containers to be run together. Thus you can see the reasons why Docker containers, and Docker as a whole, are so interesting.

Sources:

https://www.docker.com/resources/what-container

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

My name is Michael Mendes and I am a software developer in the making. I will simply be using this blog to entail my, hopefully, successful attempts to make working programs. Just to give some ideas of what to expect, I will be posting any useful tips I learn from my own personal projects and about other topics in this field I find interesting. I have always had an interest in game design as well so some posts related to this may crop up from time to time. Thanks for reading!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.