The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Throughout my time in numerous computer science classes, API has been a common term that I’ve heard, but I never actually knew what it meant or what it did. I was happy to finally learn about it during class activities and in the introduction of Thea’s Pantry. I found an article by AWS explaining more in depth what APIs are.

What are APIs?

API stands for Application Programming Interface and is a mechanism that enables two software components to communicate with each other using a set of definitions and protocols, similar to the communication between the front end and the back end in Thea’s Pantry. The application sending the request is referred to as the client, and the application responding to the request is the server. In relation to Thea’s Pantry, the front end is the client making calls to the back end, which is the server in this case. Different types of APIs exist such as SOAP, RPC, Websocket, and REST. REST APIs are the most flexible and most popular, and are also the type that we are using in Thea’s Pantry.

REST API

REST APIs are so popular and flexible because the client sends requests to the server as data, and the server uses the client input to start internal functions and send output data back to the client. REST stands for Representational State Transfer and the API uses functions such as GET, PUT, and DELETE in order to access server data. These functions were seen and tested out in recent class activities. The main feature however is statelessness, which means that servers do not save client data between requests. This is a great benefit because it provides scalability, reliability, simplicity and many other key advantages. It is a very good idea to add security to APIs, and REST APIs can be secured by using authorization tokens and API keys.

How to use and API

The first step to using an API is obtaining an API key, which is accomplished by creating a verified account with an API provider. Next, set up an HTTP API client, which will allow you to structure API requests using the API keys. GET, PUT, and DELETE are all HTTP methods for the REST API as seen in class. Even if you do not have an HTTP client, it is still possible to structure requests by yourself in your browser by referring to the documentation of the selected API. And once you understand the API syntax, you are ready to use it on your code.

Source

https://aws.amazon.com/what-is/api

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

The article “What Is a REST API?
Examples, Uses, and Challenges”, published on the Postman blog, provides an
accessible overview of REST APIs. Rest Api works as a backbone in modern web
communication. It explains that a REST API (Representational State Transfer) is
a standardized way for systems to exchange data over the web using common HTTP
methods such as GET, POST, PUT, and DELETE. It briefly explains the history of
the rest api and the comparing to Simple Object Access Protocol (SOAP) api
which required strict message formatting and heavier data exchange while REST api
emerged as a lighter and more flexible architectural style built on standard
HTTP methods. The piece also informs best practices for using REST api like using
correct HTTP status codes, providing helpful error messages, enforcing security
through HTTPS and tokens, In the end, the article shows real-world examples
from well-known platforms like Twitter, Instagram, Amazon S3, and Plaid,
showing how REST APIs are used at scale in everyday applications.

As a software developer trying to be a
full stack developer, api calls were one of my weakest points since I am
struggling to understand how to use it effectively even though I tried to use
it in many areas. I had to ensure that I have a strong, up-to-date conceptual
foundation of what REST APIs are and how they are designed and used in practice
as I use. Since Postman is one of the leading platforms in the API ecosystem,
its educational resources provide an excellent reference point for gaining both
theoretical and practical understanding of how REST APIs work in real-world
development.

Even though the article was long , with YouTube
videos and hard time to understand everything, this article with postman helped
me to better understand the history and the usage of the rest api and its real-world
use compared to before. I learned that REST is not a technology or tool but an
architectural style that enforces clear separation between client and server,
promotes scalability, and ensures that each request carries all necessary
information. Later I plan to use this information to carefully use api as I plan
to create my own REST api endpoints that provide access to datasets and user
submissions while documenting things well unlike before. Ultimately, my goal is
to become comfortable enough with APIs that I can architect entire applications

article link: https://blog.postman.com/rest-api-examples/ 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

This quarter I decided to read “Understanding RESTful API design principles” by the Upsun blog, which talks about many aspects of RESTful API. I picked this because it directly relates to what we’ve been learning recently in class, and relates to a system I will have to work with next semester for my Capstone. I figured it would be a good idea to get more familiar with REST API early.

The article starts off explaining what REST (REpresentational State Transfer) actually is. It’s a “set of architectural principles that define how to design and implement these interfaces”, discussing the HTTP methods involved. Being the only API design principle I know of, I had no frame of reference for its advantages compared to other options, but the article provides a chart and compares RESTful to GraphQL (good for more efficient and specific data fetching) and gRPC (Good for microservices and streaming).

The RESTful architecture typically contains a Client, Server, and Database, but it can include additional elements such as a load balancer or a cache. The Client, Server, and Database are fairly straightforward, being the consumer, the server hosting and processing the requests, and the database to store the data. The load balancer is also intuitive to it’s name, but for the smaller scale system like the Food Pantry which is unlikely to experience a large server load at any time anyway, it’s probably unnecessary.

The article goes into 6 design principles of REST APIs. The first one, Client-server architecture, states that the client and server should operate independently to make long-term maintainability better. The second is Stateless communication, stating that each request from the client should contain all the information needed to process the request. Nothing is stored on the server, so that each request is self-contained and can be handled independently, simplifying the process. The third is Cacheable Responses. If an API response is cacheable, it should include caching headers such as “Cache Control” or “Expires”, so that the data can actually be cached and the server doesn’t need to be queried every time. The fourth principle is Layered System. In many ways this seems similar to the principle of Abstraction, where the API should operate across multiple layers without the client being aware of the layers, reducing complexity and making it so the client doesn’t have to interact directly with multiple backend servers. The fifth is Uniform Interface, stating that the way resources are interacted with (ie. HTTP Methods, URL patterns, etc.) should be standardized and uniform. The last one is Code on Demand, which the article states as optional. It states that servers can use executable code such as Javascript to extend functionality.

Many of these principles were fairly intuitive, but it’s good to have them explicitly stated anyway. Some were also directly connected to our class discussions. Things like caching and the executable code stuff are things we didn’t talk about, but I’ll keep them in mind as we do more with REST API.

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

For this blog, I read two articles that gave me more insight into why semantic versioning is important for developers. The article, “Semantic versioning: Why You Should Be Using it,” by Kitty Giraudel, from SitePoint, discusses how semantic versioning can bring clarity and predictability to software projects. The other article, “Using semantic versioning tags,” by Marc Campbell from Medium, explained how these principles apply to container environments. These articles emphasize that versioning isn’t just a label for updates, it’s a method of stability, communication, and trust between developers and their systems.

Semantic versioning, or SemVar, follows a three-part system. This is major.minor.patch. A major change is something that might break existing code. Compatibility here is not guaranteed. A minor change may add new features, but it is backward compatible. A patch can have bug fixes, small tweaks, and also remain backward compatible. This allows teams to understand the scale of an update easily.

This builds predictability and confidence. Without semantic versioning, people wouldn’t even update out of fear that any update may break their system. This allows devs to plan for upgrades and maintain a stable codebase.

This concept parallels directly to Docker images. Container images have multiple tags(exp. 1, 1.0, 1.0.1, or latest). The latest tags always point to the most recent version. More specific tags like 1.1.0 or 1.0.0 represent a snapshot in time of that release. This gives devs added flexibility. The ability to just use the 1.0  would allow you to get all the latest updates without the potential of breaking anything.

Semantic versioning is a method of communication between developers. It’s a simple but important concept like UML diagrams. This is about maintaining a level of clarity within complex systems. The more organized the system versioning is, the better off we are down the line.

When everyone is following the same structure and the same system, developers can predict the impact of their updates without having to slew through documentation or code. It allows for more transparency, which can help the team work more efficiently for larger projects. This scales whether you are using API or Docker. Symantec versioning may seem minuscule, but getting a better understanding of this will definitely help me in the long run. It reinforces good habits that reduce confusion, help collaboration, and help projects evolve with fewer issues over time

https://medium.com/@mccode/using-semantic-versioning-for-docker-image-tags-dfde8be06699

https://www.sitepoint.com/semantic-versioning-why-you-should-using/

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

Link: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

In the blog post “Best practices for REST API design,” the authors go over important guidelines for designing any type of web service through the REST architecture style. They first go over the definition of a REST API, which is an interface that follows stateless communication and cacheability, as well as other constraints. They then show off a set of recommendations for good practices, such as using nouns and not verbs in endpoint paths, accepting and responding with JSON, logically nesting hierarchical resources, handling errors with standard HTTP status codes, and many more. The blog post emphasizes greatly that keeping names consistent and adhering to web standards will ultimately make APIs easier for maintainers and clients, as it will be easier for clients to use and maintainers to support. It would also make it much easier for systems to scale properly.

I selected this blog post because we are currently talking about this topic, and we have a homework assignment going over this topic so I thought it would be helpful to gain a deeper understanding of it. Also, in past courses, such as Unix Systems Programming, we would focus on architecture and backend systems, but I never really gave it a deeper look. This blog post gives very clear guidelines for REST API design, which can be very valuable in my career if I end up working in software or if I have to build or interact with APIs in the future. In the future, I plan on applying these principles if I ultimately have to design or integrate REST services, which could be through setting up a microservice in the cloud or even connecting to one as a consumer. I will definitely look to follow the guidelines listed in the blog post, as I believe that following those will provide a good baseline for my work. These API design patterns can also help me with projects, as I can ensure that my interface layers are clean and intuitive.

Overall, I thought that this blog post was very helpful and informative, as it provided a lot of clarity on the guidelines for REST API design. Their point about using nouns in endpoint paths was a very good point, as it is better for HTTP verbs to be doing the action. While it is a small naming decision, it can end up making a big difference when it comes to readability and maintainability. In the end, this blog post improved my understanding of REST API design practices and showed me that good design isn’t just about the efficiency of the algorithms and resources, but it is also about the service and client experience.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

I decided to read Pavan Kumar S’s blog, “Refactoring 101: Code Smells – Bloaters.” This post explains a specific code smell called “bloaters,” which starts when parts of your code grow too large and become difficult to maintain. The topic of this blog connects to our course work and topics on design principles, going over code smells and refactoring just like we’ve done in our lectures and homework.

Pavan Kumar describes bloaters as a sign that a program has become overcomplicated and cluttered. He picks out examples such as long methods, large classes, and long parameter lists. Each of these examples show a situation where code tries to handle too many responsibilities at once, causing poor readability and maintainability. Kumar suggests several refactoring techniques to combat these problems, including Extract Method, Extract Class, and Introduce Parameter Object. These techniques can be used to simplify your code by breaking large structures into smaller, specialized units. The blog explains that the goal of refactoring is not to change the external behavior or output of the program but to improve its internal structure so that it remains easier to understand, test, and extend in the future.

This blog appealed to me because it provides a clear explanation of a problem I often run into in my own programming projects. When writing assignments or personal code, I tend to write long methods that handle multiple tasks without modularity or specialized methods in mind. I’m aware of this bad habit because I mostly do it as I usually work with smaller projects that don’t require too much. Although it works initially, the code quickly becomes messy and difficult to modify or expand. Reading this blog was helpful for me since I recognized I recognized my bad habit when writing code.

What stood out most to me was how important refactoring can be in design principles. This was showcased in the duck homework where we have to refactor bad code. This only reinforced the idea and helped me better digest that concept of refactoring. A bloated method or class commonly goes against these ideas by combining too many responsibilities in one place. If you refactor and divide functionality into smaller pieces, each part of the code is more manageable and much cleaner. This short concept reinforced the idea that refactoring is not simply about cleaning up code, it’s good design habit.

From this reading, I picked up on the idea that refactoring does not have to be a massive rewrite or a stressful task. Small improvements like breaking large classes into manageable ones can prevent the slow build up that often happens in growing projects. Hopefully, I can incorporate regularly reviewing my code for signs of bloat and make refactoring part of my skillset.

https://medium.com/testvagrant/refactoring-101-code-smells-bloaters-f80984859340

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

My understanding of Scrum is that it isn’t just a process or checklist; it’s a lightweight framework for solving complex problems through collaboration, transparency, and continuous improvement. The Scrum Guide defines Scrum as: “a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.” The framework is based on … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

When I first started learning about REST APIs, I thought it was just about how apps talk to each other over the internet. But after reading the REST API Tutorial, I realized that REST is much more than just sending HTTP requests. It’s an entire way of thinking about how systems communicate efficiently and reliably. … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.