https://blog.devgenius.io/what-are-rest-apis-http-api-vs-rest-api-92c2fe2bb136

For this last blog post, I decided to pick this post on the same blog as the last one, blog.devgenius.io. Admittedly I am picking too many REST API blog posts but I thought this one was a good pick because I’ve never dove deep into why we use REST APIs and what they are as well as some other types of APIs. In this blog post titled “What are REST APIs? HTTP API vs REST API” by The Educative Team (which I assume is a team of authors) they go over HTTP APIs, REST APIs, when to use REST APIs, and what to learn next.

First, they go over what an HTTP API is. It’s an API that uses Hypertext Transfer Protocol as the communication protocol between the two systems. HTTP APIs expose endpoints as API gateways for HTTP requests to have access to a server.
They also go over common alternatives to the popular REST API: GraphQL API, Falcor API, and gRPC APIs. GraphQL APIs are the second most popular form of API and seeks to correct common problems with the REST API structure. It’s open-source and designed to hold data in a tree structure. Falcor API uses much of the REST API architecture with paths and references but automates much of the request structure. Lastly, gRPC APIs are a newer API based off RPC APIs. Almost all of the processing of gRPC APIs are done by the server in RPC architectures.

Next, they go over REST APIs. REST API stands for Representational State Transfer and is an architectural pattern for creating web services. REST APIs see widespread use by application developers due to how simply it communicates with other machines over complex operations. REST is a ruleset that defines best practices for sharing data between clients and the server. It then goes into architectural requirements to be considered a REST API: Client-server, Stateless, Cacheable, Uniform Interface, and Layered System.

Lastly, it goes into when to use REST APIs, when not to, and what to learn next. For when to use REST APIs, REST APIs are great for building general-purpose applications to be scalable in the future. As for when not to, REST is a helpful tool in your toolbelt and a good general rule to follow but it shouldn’t be your programming dogma. For what to learn next, you should learn other API types so you can recognize when a situation calls for a non-REST solution.

I thought this was a good blog post to dip my toes more into REST APIs and just APIs in general. When I was working on my homework, I didn’t really give much thought into the work but when looking into the concepts of the homework more, it’s actually interesting to learn about. I also chose this blog post because it went over other API types that I should learn about if I go into front end development and I thought that was a good takeaway from this post.

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

https://blog.restcase.com/top-5-rest-api-design-problems/

For this week, I wanted to stay on topic of REST APIs because I was still working with REST APIs this week. Also, I just think REST APIs are a fun topic for me to learn about since it’s so foreign to me. Anyway, in the blog post by Guy Levin from a blog that focuses on “Architecture, Programming, Ideas and Thoughts about microservices, APIs, cloud technologies and more” linked above, he writes about the top 5 REST API design problems. The 5 problems consist of: Using body in GET requests, usage of wrong or lengthy names for parameters, defining own error code and error message, ignoring caching, and returning too much data and long response times.

To summarize the 5 problems,
Using body in GET requests: add parameters inside the body, instead of in a URL. Many servers might not even look at the body of the request when it comes to GET method.

Usage of wrong or lengthy names for parameters: Since the URI already should state what is the resource, like project, there is no need for a long name like project_id, but only id.

Defining own error code and error message: Don’t use the approach of returning a response code 200 when something went wrong, make use of standard HTTP error codes.

Ignoring caching: Try not to ignore caching and use it, caching is very useful and gives several advantages like saving network bandwidth since this the server does not return content body but relies on the browser for that.

Returning too much data and long response times: Nobody wants to call an API and get a response after 2 minutes. Start designing your REST APIs with support for pagination, sorting and filtering.

I thought the problems Levin listed were simple mistakes that he wrote about to emphasize that these are easily missed. These problems seem to come up often if he has to write about them. I picked this blog because I thought it would be more complex problems but I think the blog post was a good post to reinforce REST API fundamentals. Looking back at these problems, I don’t think I really encountered much of these problems when I was working with the backend of the pantry API. Other than caching, all of these problems I didn’t encounter which I thought was good since the pantry backend was my first encounter with REST API stuff so I was already exposed to good fundamentals.

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

https://www.toptal.com/css/why-you-need-a-css-developer

Keeping in line with my front-end blog posts, I wanted to read another blog post on front-end stuff so I decided to pick this blog post from toptal.com on CSS developers. I also decided to choose this blog post because I think CSS is the first programming language I was aware of, I only knew that it was part of web design but I was always confused looking at it’s syntax. In this blog post from Silvestar Bistrović, he runs over what CSS developers do and why we need one.

He introduces the reader with CSS developers and what they are. They’re web professionals whose primary responsibility is to deliver a polished and styled product to the visitor’s browser. Practically every website uses CSS, but CSS is often not considered an “equal” in the modern web development stack. This has led to CSS being taken for granted, sometimes even overlooked. He then goes on to explain why CSS developers are a necessary good and to have a dedicated CSS developer instead of someone who isn’t.

The blog post is sectioned into 3 sections: What Do CSS Developers Do, Why Do You Need a CSS Developer, and Wrapping Up with every section having subsections explaining further on the section. What Do CSS Developers Do covers what they do, CSS tools, techniques, and principles, CSS, the fact Javascript is everywhere, and that writing tidy HTML always matters. Why Do You Need a CSS Developer covers CSS coding standards, CSS design implementation, organizing your CSS code, CSS code in production, and what CSS developers can do for you. Wrapping Up is self explanatory, it’s a conclusion.

As mentioned earlier, CSS was the first programming language I stumbled upon. I stumbled upon it as a kid playing online games and trying to customize my profiles for sites. I didn’t know what it was at the time and just took CSS code from others and used that to format my profile for those online games. It wasn’t until now that I would stumble upon it again in class during In-class activity 15-16 and realize how important it actually is. CSS is one of the forefronts of frontend design and that was something I didn’t know until now because I haven’t dipped my toes in web dev stuff yet. At first I thought front-end web developers were supposed to be jack of all trades for front-end development but after reading this I think having someone who specializes in CSS is essential to your team and as the author says, “do you want to leave your product in the hands of a specialized professional that could polish it to perfection, or would you settle for good enough?”

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

https://blog.bitsrc.io/9-best-practices-for-optimizing-frontend-loading-time-763211621061

So last week I wrote a blog post on good practices for REST API design so naturally I had to follow it up with a blog post on good practices to follow on optimizing frontend performance since we’re working with frontend stuff this week.

This week’s blog post is about a blog post from bitsrc.io from Nethmi Wijesinghe titled “9 Best Practices for Optimizing Frontend Performance.” In this blog post, she writes about 9 best practices that will be useful to the reader to optimize frontend data loading. The 9 best practices she lists are: minify resources, reduce the number of server calls, remove unnecessary custom fonts, compress files, optimize images, apply lazy loading, caching, enable prefetching, and use a content delivery network.

To summarize the 9 practices:

1. Minify Resources: remove unnecessary, redundant data from your HTML, CSS, and JavaScript that are not required to load, such as code comments and formatting, etc.
2. Reduce the Number of Server Calls: More calls to server, more time to load. 3 ways to reduce the number of server calls include: using CSS sprites, reducing third party plugins, and preventing broken links.
3. Remove Unnecessary Custom Fonts: Self explanatory, but also you can take these 3 actions when using fonts on your website like, converting fonts to most efficient format, subset fonts to remove unused characters, and preloading fonts explicitly required.
4. Compress Files: Compress files to save loading time since larger files = longer loading time.
5. Optimize the Images: Images improve user engagement but make sure they are optimized to save loading time.
6. Apply Lazy Loading: Lazy loading allows web page to load required content first and then remaining content if needed
7. Caching: Allow caching so browsers can store the files from your website in their local cache and avoid loading same assets when revisiting
8. Enable Prefetching: Prefetching loads the resource in anticipation of their need to reduce the waiting time of the resource.
9. Use a Content Delivery Network: Using a CDN (group of servers distributed across several geographical locations that store a cached version of the content to deliver fast to the end-user) allows you to optimize loading time as well.

I picked out this blog post because we were using frontend in class during Activity 15-16 and I wanted to follow up with practices to optimize your frontend. This was one I found that was interesting but also introduced new terminology to me. Things like lazy loading, prefetching, and CDNs I didn’t know about until this reading this post. Also, I haven’t had any web dev experience prior to this class and doing the in class activities made me more interested because it was something new to me I had never touched. I knew web dev things existed I just never knew how complex it can actually get and it’s actually made me more interested in possibly pursuing a web dev position instead.

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

In the blog linked above by John Au-Yeung and Ryan Donovan, they look at “how to design REST APIs to be easy to understand for anyone consuming them, future-proof, and secure and fast since they serve data to clients that may be confidential.” The blog post starts off with an intro detailing how REST APIs are one of the most common kinds of web services today, describes a REST API’s function and addresses the problem of designing it right so the API consumer and API maintainer don’t run into any problems down the road.

The blog post is sectioned off into 7 different sections. These sections all address a good practice for designing a REST API as well as a block of code to set an example of what they mean. The 7 sections consist of Accept and respond with JSON, Use nouns instead of verbs in endpoint paths, Handle errors gracefully and return standard error codes, Allow filtering, sorting, and pagination, Maintain Good Security Practices, Cache data to improve performance, and Versioning our APIs.

To summarize the 7 sections,
Accept and respond with JSON: REST API should accept JSON for request payload and also send responses to JSON.

Use nouns instead of verbs in endpoint paths: Since verbs are already in the HTTP request, we should use nouns.

Handle errors gracefully and return standard error codes: Eliminates confusion for API users by handling errors neatly via HTTP response codes that indicate what error has occurred, this allows API maintainer to have enough info to understand problem that’s occurred.

Allow filtering, sorting, and pagination: Allowing these 3 features will increase performance by reducing usage of server resources.

Maintain Good Security Practices: Use SSL/Load a SSL certificate onto server and add role checks for users.

Cache data to improve performance: Add caching to return data from the local memory cache instead of querying the database, this would lead to getting data faster but data could be outdated.

Versioning our APIs: Version your API semantically like most apps do today.

From reading this blog post, I’ve learned more about the good practices for REST APIs. I was interested in learning more about REST APIs since it was the first time I was working them when we went over in class activity 12. Also, the blog post’s title mentioned REST API design which I thought was relevant to our class due to the class being aptly named Software Design and Architecture.

Admittedly, I didn’t learn the most helpful stuff from this article since I had learned most of it in class and by going over the in class activity with my group but I thought this blog post helps reinforce good practices if I do eventually work on REST APIs in my CS career. I’d also say that I looked into the article because of the making of endpoints for homework 4.

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

https://www.bmc.com/blogs/docker-101-introduction/#

In the above blog post by Sudip Sengupta, he introduces Docker and gives us a guide on Docker. The blog post goes over application development today, what docker is, it’s components, it’s benefits, and alternatives to Docker. In today’s application development, a common struggle is managing an application’s dependencies and technology stack across various cloud and development environment. By adopting something like Docker or a containerized framework, it allows for a stable framework without adding complexities, security vulnerabilities, and operational loose ends. Docker also makes application development easier by allowing development teams to save time, effort, and money by dockerizing their applications into single or multiple modules. Testing with Docker is also done independently (each application is in their own container) which allows testing to not impact any other components of the application. Docker also helps keep consistent versions of libraries and packages to use during the development process.

I chose this blog post because I was having a hard time in class understanding Docker. I tried to view it as a virtual machine, which was somewhat right, but is actually more efficient than a virtual machine since you won’t have to run a virtual machine and use a lot more resources than needed. Compare that to a Docker container which contains all dependencies, libraries, and config files, Docker would be the much more viable option to use in the long run in my opinion, virtual machines just take too much resources (they require significant RAM and GPU resources since they run a separate OS and a virtual copy of all the hardware the OS requires) and Docker containers, or application containers in general, are more flexible and portable than a VM.

You can see why Docker is being adopted more, it’s because it’s much more efficient and easier to use while developing an application. With this blog post, I’ve learned a lot more about Docker and why it’s used. I thought this was a good blog post because it helped get a better understanding of why Docker is used in application development and helps me familiarize myself more with technology I’ll most likely be using when I get a professional job and start developing applications with a team. In the future, I expect to have to learn more Docker or application containerization in general for my job as a software developer and having the knowledge of Docker beforehand and why developers use it, is very useful.

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