Category Archives: Week-15

Week 15 II: What Are REST APIs? HTTP API vs REST API

For this last blog post, I decided to pick this post on the same blog as the last one, 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.


Hello, blog (mood-status: relax), writing this blog after coming home from work, finishing the exams, and submitting assignments. But anyway, on writing about this week-15. I am writing this as my “final” blog for the year 2021 for real. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Patterns & anti-patterns.



Patterns are part of everyday language, but it’s essential to discuss algorithms to understand their importance in software engineering. An algorithm performs a daily task like sorting a list of items, storing data for efficient retrieval, or counting occurrences of an object within a data set.

 Algorithms are among the most used fundamental concepts in software engineering. It mainly highlights proofs of its solutions and its only code samples in obscure, ancient languages such as Algol or MIX Assembly. Despite much covered: singly- and double-linked lists, trees, garbage collection, etc. The details are hiding in problematic libraries, but the concepts are the same. These algorithms have remained reasonable solutions to common software engineering problems for more than five decades and are still going strong.

A “pattern” can be a general structure of an algorithm. In algorithm focus on a specific programming task, a pattern challenges beyond that domain and areas such as reducing defect rates, increasing code maintainability or allowing large teams to work more effectively together. Some standard practices include:

  • Factories
  • Pub/Sub
  • Public-key Cryptography
  • Agile


These are four common patterns in the industry; it ranges from highly technical to broader, more process-oriented points. Factories are very code-oriented, while pub/sub is more architectural. While public-key cryptography has general importance, libraries to support its operations are available for almost every programming language in everyday use, making it generally short of implementation.

At the other end of the expanse, “Agile” remains unavailable: a point and a tool among developers, project managers, and other stakeholders about precisely what it means and how it should be implemented. From Narrow or broad, technical or process-oriented, excellent working knowledge of these patterns is an essential component in a technologist’s toolbox.


What is an Anti-Pattern?

A “pattern” is a known-to-work solution to a common software engineering problem (anti-pattern). Anti-patterns do not incorporate the idea of failure to do the right thing, including options that seem right at face value but direct to trouble in the long run.

Note the reference to “a common response.” Anti-patterns are not a few mistakes; they are familiar and always followed with good choices. As with regular patterns, anti-patterns can be broad or very specific, and there may be hundreds to consider in the realms of programming languages and frameworks.

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

Week 15: Top 5 REST API 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.

Changing your Approach to Testing

I’ve always avoided familiarizing myself with the practice of testing, as the models and math required to really understand it seems to be quite daunting. On an episode of Coding and Cocktails by the name of Changing your Approach to Testing, Alan Richardson outlines a shift in how we should think about testing. The thing that immediately struck me was his outline of how testing in the industry is a tad lackluster – for the reasons that I avoided it in the first place. Apparently, people haven’t read up on past research and existing models to optimize their techniques of testing. Richardson references the difficulty of testing for beginners, and a disconnect between those that specialize in it versus those who are not as versed in the practice. I could sense a tinge of frustration from Richardson as he outlined a general lack of familiarity with the field, noting a soft disregard of math techniques like set theory, graph theory, probability theory, etc. He stressed the technical knowledge and deep analysis needed to effectively do the job, as well as the interpersonal communication techniques needed to address problems with colleagues. 

I found it particularly intriguing when Richardson referenced the need to effectively communicate with team members with the right language for that individual, especially in the case they don’t want your feedback. He noted that this could be seen as “people skills,” but further explained he actually studied psychology to better understand his interactions and optimize the team’s communicative efficiency. Quickly after however, Richardson pumps the brakes a bit to say one need not possess every good quality for being a tester – after all, what are teams for? As long as aspects like technical know-how, tenacity to finish and the ability to challenge people are represented in the team, members can work off others’ strengths while being valuable for their own. I must say this relieved a bit of my anxiety because of the huge pool of knowledge that must be drawn from, be it interpersonal or technical. 

Furthermore, he stressed the application of the tests, and how to go about asking the right questions when designing them. The example Richardson brings up is a basic question that should always be asked before any work is done – what is the goal of testing this specific product, and how should tests be implemented based on that goal? I believe he stressed this point because he asserted that a majority of the industry is relatively inflexible when adapting to different testing environments. As mentioned prior, this is most likely due to an unfamiliarity with the literature and research. 

As much as I enjoyed the perspective, and will definitely remember this episode for future reference and tips, it has only made me more terrified of testing. At least I know what I should be doing though, right?

Link –

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Exploring Fintech Innovations

For this post, I tuned in to the Code and Cocktails episode by the name Exploring Fintech Innovations. Amancio Bouza, API thought leader and chief product officer at Contovista AG, represents an area in tech known as fintech, or financial technology. This field describes how technology can improve and optimize delivery and use of financial services. The episode delves into the intricacies of modern banking, and describes how woefully behind banking is in the modern era. Some institutions are so large they disregard the need for things like API implementation entirely, thinking that they have a few years before it becomes essential. To combat this, consultants like Bouza educate banks on the future necessity of the technology. 

For example, upgrading certain models of data analysis could provide statistics on customer preferences and expectations. Thus, this information coupled with machine learning has the potential to tailor specific financial advice to a user at an individual level. This could theoretically be massively beneficial to a bank’s constituents, by educating them on specific pitfalls and nuances of their financial situation, hopefully pushing them to accrue more wealth once they understand the data. Once the understanding of some patterns and validity of different models are smoothed out with machine learning, it also greatly helps with risk management for both the individual and the bank itself. 

In addition, Bouza notes that in the next decade or so society will shift to a more decentralized payment model, with debit and credit cards being phased out for account-based financial transfers. This is an infrastructure many larger banks need to adapt to, as Bouza notes the autonomy granted by such a shift will be an inevitable draw for modern day consumers. He references a “lack of urgency” in these large institutions, whereas startups who are on the razor’s edge of success or failure will scramble to be ahead of the curve of general tech implementation to keep up with the market. In the classic capitalistic train of thought, they consider themselves too big to fail.       

I think it’s also important to mention that people like Bouza are far from wanting to totally restructure the system. He’s working to educate existing entities and give them the tools to prosper in the coming future – tools that will benefit both the institution and the consumers. By incorporating even a small portion of Bouza’s suggestions, people can take advantage of the autonomy given to them to invest in hyper personalized interests. Autonomous finances have the ability to make each consumer the most wealthy and frugal that they have the potential to be, which is a net win for everyone involved.

Link –

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

The State of APIs in 2021

I recently discovered a podcast by the name of Coding over Cocktails, and they’ve done some excellent interviews with professionals in the field that specialize in API design. Evidently, the infrastructure of APIs are poorly maintenanced in many cases, as the importance of the practice has not yet hit the general understanding of how important they will come to be in future design strata. Matthew Reinbold, the interviewee on the episode titled The State of the API in 2021, asserted that there are a few key ways to see the “articulated vision” for how APIs interact and benefit future implementations of software. 

Reinbold outlined the need to be able to articulate how technological modularity is a strategic boon to the industry. While at the moment API design is proverbially left on the cutting room floor, he stressed the growing importance of integrating the practice as a cornerstone of future project endeavors. Referencing the pandemic, he cites a slew of examples pertaining to the cultural shift in society and the changing needs of consumers. For example, if an API was properly implemented for a given company, they ended up being months ahead of other organizations who failed to recognize the importance of the practice. These cultural shifts like curbside pickup are now a staple in modern business practices, and are here to stay for good.

API implementation promotes independence for consumers and resiliency to change for businesses, but at the moment are a “it would be cool if we had that” type of implementation in most projects.

Reinbold goes on to say that work culture norms are the primary thing that has to change before executives see the potential gain from incorporating such software. Changes to management would undoubtedly be the primary driver, but Reinbold also stresses the agency that lower tier employees don’t think they have in the industry. He uses the comical and stereotypical image of a computer geek living in a basement, where all one has to do is “throw pizza and sugary drinks down the stairs and code comes out.” In reality however, Reinbold argues that younger workers or “new power” feel helpless in the face of their superiors, or “old power.” But the mantle of leading change, Reinbold states, is simply finding the correct skills and techniques to do things better, and to try and get one’s colleagues intrigued with the implementation. The dynamic between new and old power is irrelevant if genuinely good ideas and leadership are explored at all levels. 

Either way, it was fascinating to hear about something we studied in class as the next step in tangibly improving our technology and quality of life. 

Link –

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Retreat into Competence

For the last and final blog post in my capstone class, I focused on the apprenticeship pattern of “Retreat into Competence” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about perhaps how you are overwhelmed or beginning to realize how little you know, or perhaps you have taken on a new challenge and things are not working out so well. However, getting back into something you are good at is a nice way of regaining your composure. I completely agree with this statement, sometimes all we need a just a pullback to launch forward towards the goal. The quote provided at the beginning of the section is what stood out to me the most. It states that “You look at where you’re going and where you are and it never makes sense, but then you look back at where you’ve been, and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something.” This got me thinking very deeply about the past four years of college and my CS Journey. I have no idea what the future hold, but one day I will look back to see where I have been and possibly see a pattern emerge.

The author also mentioned how apprenticeship is a roller-coaster ride, you will experience the thrill of new technologies, but you will also experience struggles as just how little you know compared to the craftsmen and experts you meet along the way. It is important that Sometimes you need to take one step back to take two steps forward. But it is essential to move forwards as quickly as possible because the forward momentum is revealed in your possession of more knowledge and greater skill than you had yesterday. Another important aspect the author mentioned is how to seek support from your mentors, with their support and boost you can be on the right track again and display competence. In this way, you will be more equipped for future challenges. The patterns displayed a lot of insights towards my career and on a personal level. I will certainly be reading more patterns from this book even though this is my last and final blog post for the CS-448 class.


From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Use the Source Luke – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Use the Source” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is for people who have not developed in environments that have stressed the importance of the ability to read source code. Developers often spend much more time reading source code than actually writing it. Often times developers cannot understand the code and have to rewrite it themselves. As stated in the book, Bill Gates once said, “one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through it and understand it”. People who can absorb design patterns, algorithms and data structures through real code become great programmers because they are learning from every good programmer each line at a time.

The authors suggest picking an algorithmically sophisticated open source project and take note of the algorithms, data structures, and design decisions made in the code that are new to you. Then, write a blog post for each new idea you learned. While doing this, download the lates version of the project and try to work out why the developers made certain decisions in the design and architecture and try to work out ways you would have done it. Figure out if your way wouldn’t work or would actually be a better solution. This will cause you to think deeper about the reason the project is coded the way it is.

I found this design pattern very interesting because I would agree that the ability to read code is very important and my lack of experience doing so has caused me lots of problems in the past. Often times I have had to rewrite code I was not able to understand or attempt multiple times to understand a piece of source code before finally getting it. I would say that I have improved, but there is still lots of room for improvement in the future. I like the idea of examining open source projects and I think I will do so very soon.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Be The Worst

The section “Be The Worst”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on situations where you aren’t able to learn much from your environment. Being on a strong team has its benefits, other members can cover areas where you are weak on and catch you before making mistakes among other things. Ideally, a team member should be able to take a step back from their team to accurately assess their skill and knowledge. In the case where the gap in skill or knowledge between yourself and other team members in vastly in your favor, then it’s likely that you won’t be able to grow much as a software developer. Because of this, it’s best to start out as the weakest member of a team, hence “Be The Worst”, in order to have room to learn and grow. Emphasis on “start out”; the weaker members of a team should work more to catch up to the rest of their teams. If they don’t bother, then the “Be The Worst” pattern kind of loses its whole point.

Fortunately, or unfortunately depending on how you look at it, I’ve never felt that I was the strongest in a team skill wise. Some of the people I’ve worked with on a team do things super quickly so I had to adapt by starting tasks early and refamiliarizing myself with certain concepts. I guess you could consider that a method of catching up with other team members. In a team setting, I don’t actively try to “Be The Worst” but I at the very least understand why it’s a pattern. If people aren’t challenged, then they’re tempted to stagnate and it becomes all too easy to end up as a big fish in a small pond. When someone better inevitably comes along, then those who’ve done nothing to improve are thrown for a loop and can’t easily adapt to that change. Though, people could also be motivated to do the opposite; work catch up or even surpass their peers in order to not be seen as the weak link.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Share What You Learn

The problem of this pattern is one of the final ones, as far as I can tell. It is framed around your near-completion as a developer. I mean this in the sense that you’re a rounded-out developer with a lot of useful skills, but not necessarily a significant amount of real-world experience. In order to truly become a journeyman, you need effective communication skills. It isn’t enough to be a good programmer.

In order to gain such skills, the proposed way is to share that which you have learned. One such way is via a blog such as the one you’re currently reading. I pretty much completely agree with this pattern. I think the best way to learn things is to explain them to someone else. Really, the reason that we are tasked to write large essays in high school and college, despite them being annoying, is because writing is thinking. If you are capable of reading these words, then you’re most likely literate. Modern people take literacy for granted. For millions of years, the vast majority of humans were illiterate and as such their brains developed in a different manner to ours.

According to a discussion with Psychologist Jordan Peterson (that I unfortunately cannot find to link here), illiterate people think differently than literate people. Illiterate people think more in images and experiences, similar to how animals think. (Don’t let your arrogance get the better of you; all humans are animals biologically.) Words themselves are abstractions and your brain has to handle abstractions differently. It has to convert from symbols and sounds to the word to the meaning of the word. I would say that tribes of people that rely heavily on the oral are similarly affected. Nonetheless, literacy has a profound effect on your brain and thus how you learn. Writing is a form of thinking. Literate people have the ability to write or type words without really planning it in their minds, similar to how people can speak without thinking. The words are the thinking. So, when you explain something, you need to find the words to describe it and that process is thinking.

That’s why written words can be so messy; we think through them as we write. Thoughts are messy. So, it is essential to be an effective communicator not only to benefit others. Ignoring the existence of other people, being an effective communicator means you are an effective thinker. This is specifically in terms of words, which I would argue programming requires. The concepts dealt with in programming require intense mental abstractions that most of us take for granted. There’s a reason the general population thinks coding is magic. It’s simply too abstract to fully grasp from a single viewing. This means words are the way we handle that abstraction. Thus, make yourself powerful with words in order to become powerful in your actions as a programmer.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.