REST Easy: The API Guide Everyone Needs

In a world where apps constantly exchange information, REST APIs play a major role in making that communication fast, smooth, and reliable. Whether you’re checking your bank balance, ordering Uber Eats, or posting on Instagram, a REST API is working behind the scenes. But what exactly is a REST API, and why does it matter? Let’s break it down in a beginner-friendly way.

What Is a REST API?

A REST (Representational State Transfer) API is a set of rules that allows different software systems to communicate over the internet using simple, predictable URLs. REST is not a programming language, it’s an architectural style that uses standard HTTP methods like GET, POST, PUT, and DELETE to perform operations.

For example:

  • GET retrieves data
  • POST creates new data
  • PUT/PATCH updates data
  • DELETE removes data

Because REST uses these familiar operations, it is easy to understand and widely supported across web technologies.

How REST APIs Work

REST APIs treat everything as a resource, which is represented by a URL. For example, an e-commerce API might represent a product like this:

GET https://api.example.com/users/25

When your app sends that request, the API returns a response often in JSON, a lightweight format that is easy for humans and machines to read.

REST APIs follow a key principle: statelessness. This means the server does not store any information about past requests. Each request must contain everything needed to understand it. This makes REST fast, scalable, and ideal for large applications.

Why REST APIs Are So Popular

Because REST is simple, flexible, and language-independent, it has become the backbone of modern web and mobile development. Companies like Google, Amazon, Meta, Stripe, and Spotify structure their services around REST principles.

  • Simple — They use familiar web protocols like HTTP.
  • Flexible — You can use them with any programming language.
  • Scalable — They handle heavy traffic without breaking.
  • Separation-friendly — Frontend and backend teams can work independently.

Companies like Spotify, Google, and Amazon depend heavily on REST APIs to integrate services and deliver smooth user experiences.

Developers prefer REST APIs because:

  • They are easy to build and maintain
  • They work across many platforms
  • They separate frontend and backend development

In short, REST APIs allow apps to interact smoothly, reliably, and efficiently—powering almost everything we do online.

Conclusion

REST APIs remain one of the most important tools in modern software development. Their simplicity and scalability make them ideal for beginners and professionals alike. Whether you’re building your first backend or integrating external services into an app, understanding REST APIs is essential in today’s tech landscape.

References:

https://www.ibm.com/think/topics/rest-apis

https://www.redhat.com/en/topics/api/what-is-a-rest-api

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

https://www.codecademy.com/article/what-is-rest-api

From the blog CS@Worcester – MY_BLOG_ by Serah Matovu and used with permission of the author. All other rights reserved by the author.

Blog 4 – Software License

In our world, when you want to drive a car outside the public, you would need a driving license to do so. This is because you need the permission to use the road freely. Also, if you want to go fishing, you also need a fishing license, this gives you the permission to fish at any public lake or public fishing area. As we know, license provides you the authorization to access something that requires from someone’s permission. Same with software engineering, in software, we require license to access someone’s code or project. It grants right for you without transferring ownership from the author. However, there are multiple types of software licenses, each has their own function. I will explain everything in this blog based on what I read from https://finquery.com/blog/software-licenses-explained-examples-management/

What is a software license?

A software license is a legal agreement between the software creator/provider and the user (individual or organization) that defines how the software may be used. It doesn’t transfer ownership — it grants rights.

The license specifies things like how many devices you can install on, whether distribution or modification is allowed, and other restrictions (or freedoms) depending on the license type.

How licenses work & why they matter?

When you obtain software, what you actually pay for is the right to use that software under certain terms, not the software itself.

Licenses protect the intellectual property rights of developers, control distribution, and can also allow or forbid modification. That helps prevent piracy and misuse.

Before using software, users often must agree to an End User License Agreement (EULA) — a legally binding contract defining permitted and prohibited actions under that license.

Common Types of Software Licenses

  • Public domain license: No restrictions — software is effectively “free for all.” Anyone can use, modify, relicense, or commercially exploit it without needing to pay or give credit.
  • GNU Lesser General Public License (LGPL): Open-source license allowing developers to use/license the code in their own projects without having to release their own source code.
  • Permissive license: A flexible open-source license with minimal restrictions — typically just requiring attribution/copyright notice on redistribution. Common in open-source community
  • Copyleft license: More restrictive open-source license: if you modify and distribute the software, you must also make your version’s source code freely available under the same license
  • Proprietary license: Most restrictive — software remains proprietary, users get limited rights; typically no access to source code, and strict limits on copying, sharing, modification, or redistribution.

Software License Management

Because organizations often use many pieces of software (some licensed, some subscription-based), managing this properly is important. The article recommends:

  • Keeping a centralized inventory of all software licenses and subscriptions used within the organization.
  • Tracking license usage, renewals, and compliance — ideally via a dedicated license-management tool rather than manual spreadsheets.
  • Establishing reminders for renewals and conducting regular audits to avoid under- or over-licensing, penalties, or wasted spending

Conclusion

If you ever find an interested code, or project, that you want to install it in your computer or use it as references, make sure to keep an eye on its license. Identify its type, and follow the permission it allows. This keeps you avoid any legal risks, control costs, and efficiently manage software assets.

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

Week 4 – CS 343 Blog: What is front-end?

Have you ever wondered everything you see on your phone’s screen in any of applications you clicked on, how do they work that makes you be able to interact with it? Of course, they’re programmed by the programmers, but in order to design the app and allow users to interact with the app, it’s not just about programming, it’s a whole process of implementing what is called “Front End”. So, what is front-end? Why does it matters in building an application or website?, who takes control of it? Everything will be explained in this blog based on what I read from https://airfocus.com/glossary/what-is-a-front-end/ by airfocus, “Front End (in website).

What is front end?

The front end refers to everything a user sees or interacts with when using a website or app. That includes layout, design, buttons, navigation menus, images — in short, the look and feel / user interface.

Technically, front-end work is implemented using web languages like HTML, CSS, and JavaScript.

In contrast, the back end handles behind-the-scenes functionality: data processing, business logic, server communications. The front end and back end together must work smoothly to deliver a good user experience.

Why Font End decisions matter?

According to airfocus, front-end design is critical for product success because:

  • User engagement & satisfaction: A well-designed front end makes it easier and more enjoyable for users to interact with the product — reducing friction, boosting clarity, building trust.
  • Ease of iteration and experimentation: Clean, intuitive front-end design allows product teams to iterate faster — experiment with UI/UX improvements, adjust features based on feedback, without overhauling the whole system.
  • Brand perception & consistency: A consistent, polished front end across platforms (web, mobile, etc.) strengthens brand identity and trust. A clunky or inconsistent UI risks undermining user perception of the brand

Roles & Collaboration: Who shapes the front-end — and how product leaders fit in

While front-end code is done by engineers / front-end developers, product managers (or product leaders) have a crucial role: they translate user needs and business goals into clear priorities for what the front end should deliver.

Product leaders don’t need to write code — but they should understand dependencies between front-end and back-end, and advocate for a user-centered design that balances business constraints, technical constraints, and user experience.

Effective front-end strategy means collaborating with design and engineering leads, making trade-offs transparent, and using structured planning tools (roadmaps, scoring, templates) to guide front-end work.

Conclusion

Overall, front-end developers is a very important position in building an app, or website. Specifically, front-end is like an appearance of what you can see and interact with within the app. If there is no front-end implementation, there is no app or website even exists.

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

Bridging Frontend and Backend Development: My starting journey building therapeutic platforms

For this final blog post, I have decided to explore the realms of frontend and backend development. It has been an informational and exciting journey learning about backend development in my Software Construction, Design, and Architecture course, and with my background in psychology, I am driven by the curiosity of bridging these two fields. My current interest is figuring out how to use computer science to improve and aid mental health through application development.

This is something we currently see in terms of self-care apps and a handful of psychology games. I want to expand by building therapeutic platforms, engaging psycho-educational games, and functional apps for psychology. This goal pulls me in both directions of developing skills in frontend and backend development. I looked at a few resources to learn more about the characteristics of frontend versus backend, and this GeeksforGeeks resource provided a great starting point for understanding the characteristics of these domains, what skills I should develop, and what technologies I should become more familiar with.

The modern web is built upon two domains. As resources from GeeksforGeeks and FullScale clarify, these roles are functionally different and equally necessary for any application to thrive. The Frontend(Client-side) is the visible and interactive layer. It is responsible for all user interaction, visual presentation, responsiveness, and application behavior, using technologies like HTML, CSS, and JavaScript. This layer controls the user interface and user experience (UI/UX), defining what users see and how they interact with the platform.

On the other hand, the Backend(Server-side) is the behind-the-scenes infrastructure. This layer manages crucial processes like data (processing and management), storage retrieval, security protocols, user authentication, and ensuring the frontend receives the needed/requested information.

What really draws me to frontend development is the idea of using UI/UX as a therapeutic mechanism. This is where my psychology background connects directly with code. The interface itself determines how well an intervention works. For example, if I am building a tool for guided imagery or relaxation/deep breathing, the success is not just about the back-end data, but about making sure the visual cues and flow are seamless and actually helpful for the user. A clunky design can easily increase stress or cognitive load, thus undermining the whole point of the tool. As the resource “Journey of a frontend developer” states, this path is not just about making things aesthetically pleasing; it is about mastering responsive design and translating complex human needs and psychological principles into structured digital architectures. 


While my dive into frontend and backend began with an interest in frontend work (UI/UX), I recognize that knowledge in both areas is crucial to being a well-rounded developer and producing quality products. You simply cannot have a stable and secure platform without the backend part, due to the necessity of its operations. This balanced approach is the best way to build fully functional and high-integrity tools and to successfully merge my technical skills with my professional interests.

Main Resources:
Frontend Vs Backend Development – https://www.geeksforgeeks.org/blogs/frontend-vs-backend/#

Frontend VS. Backend Software Development – https://fullscale.io/blog/front-end-vs-back-end-software-development/

Journey Of a Frontend Developer – https://medium.com/@ravindermahajan/journey-of-a-frontend-developer-9d09ab36dcd5

Additional Resources:
Frontend? Gross. This is Why I’ve Always Preferred the Backend – https://blog.boot.dev/backend/why-i-prefer-backend/

Going to Backend Development from a Frontend Developer’s Point of View – https://medium.com/@garciajvincent/going-to-backend-development-from-a-frontend-developers-point-of-view-6d7081609c56

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

The Importance of Frontend Development

Frontend development is an essential part of building any website or just an application. It is the part of web development responsible for what the users see and interact with the user interface  and user experience of a website or application. The author explains that the frontend is built using technologies like HTML, CSS, and JavaScript. HTML is the backbone of any webpage because it provides structure and organization with defining things like headings, images, paragraphs, and links. CSS works with HTML by controlling the visual representation of the page and allows developers to customize colors, fonts, and layouts. Meanwhile JavaScript adds interactivity, handling user input, and dynamic behaviors to the page. These all work together The article also outlines typical tools and practices used by frontend developers like code editors, local development servers , version control systems, package managers, and build tools. In addition, it talks about styling techniques, making content responsive, adding interactivity via DOM manipulation and event handling, and using frontend frameworks or libraries to streamline development. Overall the article supports advancing your frontend development skills and makes it much simpler going in as a beginner who doesn’t know much about it beforehand.

The reason I chose this article is because in our class we have used the backend code for Maria’s Pantry many times, but we had never really used the frontend until the very end of the semester. Since we didn’t have as much time to go over it I also found myself very confused at times as to what was the major difference and how important is it really. I mainly just wanted to do my own research and read about it since I felt it would be something extremely important to know as much as possible to any developer.

After reading the blog post I started to realize how important HTML, CSS, and Javascript were to frontend development. They hold up and give structure to the webpage. This post also names some courses you may take to practice frontend development like udemy, coursera, and codecademy that cover most of the basics behind HTML, CSS, and Javascript. I plan to look up on them and try to practice as much as I can cause I would like to work on my skills as much as possible as I believe that it would be valuable to any sort of career I may look forward to in web development.

https://namtheartist95.medium.com/what-is-frontend-development-5fdfdd892464

From the blog Thanas CS343 Blog by tlara1f9a6bfb54 and used with permission of the author. All other rights reserved by the author.

Improving API Documentation

OpenAPI and Swagger are huge tools that software developers use every day. It is extremely important to use when it comes to building clear, maintainable, and interactive API documentation. The name of the article I chose was “How to improve API documentation with Swagger and OpenAPI”. According to this article, APIs are central to modern software design, and their documentation plays a critical role in ensuring that developers can consume them and maintain them correctly. “Using the OpenAPI Specification with the Swagger ecosystem offers the much-needed standardization to REST API documentation”. Besides, it explains that the OpenAPI Specification is human- and machine-readable, it clearly states the structure of the API, its endpoints, parameters, responses, and data models. This in turn helps reduce ambiguity, which often results from loosely documented APIs.

Besides these, there are several tools that come with Swagger, including the editor, UI, codegen, and inspector. It allows developers to design and edit OpenAPI definitions in JSON or YAML with built-in validation so syntax errors can be caught right there and then. The UI presents OpenAPI definitions as documentation that users can try API endpoints from within their web browser. Codegen produces client libraries, server stubs, and SDKs that facilitate rapid development on multiple platforms. Finally, the inspector is a tool for testing APIs directly and generating an OpenAPI definition based on existing APIs.

There’s also an updated version, allowing for more modularity and an approach to defining the surface area of an API, with the official release of OpenAPI 3.0. This provides even greater flexibility in describing the request and response model of an API. Good schema and component reuse are emphasized in the most recent version, and handling of multipart documents. Advertisements.The reason I chose this topic was because we have been doing a lot of work with swagger and APIs, and I wanted to look closely into how vital it is to be a software developer in the real world. I also wanted to look closer into how swagger can improve my design skills. After reading this article, I started to see why proper documentation isn’t just something nice and handy but a necessity in being a skilled developer. From now on, I plan to strengthen my understanding of swagger and APIs because I think it will also help me in improving my coding skills and future project.

Resources: https://www.techtarget.com/searchapparchitecture/tip/How-to-improve-API-documentation-with-Swagger-and-OpenAPI

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

Companies and API Security

I recently wrote about an article that discussed important security practices for implementing APIs. Security seems like something that could not be overlooked by major companies, but 65 percent of Forbes AI 50 companies have leaked verified secrets on GitHub. Supposedly, VS Code extensions keep making things such as API keys, tokens, and other digital credentials known when uploaded to GitHub. One of the researchers attributes this partially to “vibe coding”. Recently, it has been discovered that LLMs have been able to give up API keys with certain prompts. With the rise of the usage of LLMs, this can be incredibly dangerous for these companies. Wiz is a security company that sells secret scanning as a service. It was recently purchased by Google for $32 billion. Wiz found that the most common sources of these leaks were Jupyter Notebooks, Python files, and environment files. The keys and tokens found in these leaks are ones that could cause for severe issues for these companies. These keys could also expose training data that may include sensitive business data. Wiz says that multiple companies who were found to have these leaks were notified about the exposures, but half the security disclosures either couldn’t be delivered or received no response. The article ends by saying: “The first step toward solving your secret exposure problem is admitting that you have a problem.”

This was very surprising to me. As I have been learning about APIs, I have realized how important it is to ensure that everything is secure. When I had read the other day about API security practices, I thought that these were standard practices that companies would not omit. When I had seen this article, I figured that I had to read it. It was such a shock to me that high-level tech companies would omit such an important step in API implementation at such a high rate. To make matters worse, many of them did not attempt to clean this issue up. The last line of the article really stood out to me. I couldn’t imagine being a part of such an important company and ignoring such a large issue. As AI continues to grow, I believe the companies that make an effort to keep their systems secure will be the ones that flourish. Overall, this article opened my eyes to a lot. It seems to me that it is good that I am learning about APIs now, as large AI companies still have a lot to learn as well.

https://www.theregister.com/2025/11/10/ai_companies_private_api_keys_github/

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

Choosing Code Rules: Navigating Licensing for Health Technology

Understanding software licensing is one of the crucial, non-coding topics that becomes a massive deal the moment you start building real applications. When covering this in my Software Process Management course, I was overwhelmed by the density and intimidation of the numerous license types and legal details. For this blog post, I decided to use this opportunity to strengthen my understanding of these various software licenses. This information is vital for my plans, especially when creating high-integrity therapeutic platforms where security and protecting ideas are non-negotiable. To achieve this goal, I looked at several resources to deepen my understanding.

To make sense of licensing, the best first step is grouping them into two major categories: Proprietary (Closed source) and Open Source. As the resource by Zluri, “3 Major Types of Software Licenses & Its Categories” states, proprietary licenses are the most restrictive type as their whole purpose is to keep the source/base code private. This means, you can only use the software via permission and under strict conditions; you will not be able to edit or distribute the code yourself. For my work, this proprietary model might be necessary to protect the specific clinical methodology or algorithms I develop for future therapeutic platforms. Open source licenses, on the other hand, make the source code publicly available, which is the best for those who are looking for collaboration and efficiency.

However, this resource by BlackDuck states, open source licenses can become overwhelming. To best understand, I grouped the following licenses from easiest to more difficult to handle. Permissive Licenses (i.e., MIT and Apache 2.0) are the easiest to use as they are very flexible and only require you to include the original copyright notice. Copyleft licenses (i.e., GPL) have a strict rule to follow. That is, if you distribute a modified version of software, you must also make your modified source code available under the same copyleft license. If I used a copyleft feature in a therapeutic game, for example, I would be forced to release the source code of my entire game; which is a major factor protecting the core methodology and design. 

Licensing is more about just reading and considering rules, strategic planning is very important with choosing which to work with. It directly impacts ethics, decisions, and compliance of any platform handling sensitive information. If I am to build things like interactive feedback systems or symptom management trackers, I need to know exactly which third-party tools I can safely use. My current task is figuring out that delicate balance to ensure I build professional, compliant, and sustainable software that protects both users and the core therapeutic intervention.  

Main Resources:
3 Major Types of Software Licenses & Its Categories – https://www.zluri.com/blog/types-of-software-licenses

Five types of software licenses you need to understand – https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

Additional Resources:
Software Licensing Models: Your Complete Guide – https://www.revenera.com/blog/software-monetization/software-licensing-models-types/

Software License Types, Examples, Management, & More Explained – https://finquery.com/blog/software-licenses-explained-examples-management/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

Design Patterns

Hello everyone,

This will be my last blog of the semester and being the last one, I wanted to do something fun. When we went over Design Patterns in class, I was really amazed and I saw myself going back and thinking about it. I was even surprised to see that I had not written a blog about it. I wanted to do a little digging and wanted to talk in this week’s blog about a new Design Patterns that we didn’t cover in class, and the one I am going to talk about is “…drum rolls please…” Adapter Pattern!!!!

The idea behind it is pretty simple and as you can guess it comes from the name, and its general idea of it in software development is identical to the one in the physical world. When you travel abroad and want to charge your phone or laptop but the power outlet has a different shape from what you are used to seeing back home. In a different scenario, you are going to connect your old console to your new TV, but the plugs and outlet are not compatible so what do you do? In both of these cases you are going to use an adapter which allows you to use your own plugs in scenarios where you normally were not able to.The Adapter Pattern has the same principle but it is applied in object-oriented programming. A prime example of when this is used is when you already have a class and want to reuse in a different interface and rather than creating a whole new class just for that specific interface, youuse the Adapter Pattern. You then implement a class that bridges the gap between an expected interface and an existing class. That enables you to reuse an existing class that doesn’t implement a required interface and to use the functionality of multiple classes, that would otherwise be incompatible.The biggest advantage of the Adapter Pattern is that you don’t need to change the existing class or interface. By introducing a new class, which acts as an adapter between the interface and the class, you avoid any changes to the existing code. That limits the scope of your changes to your software component and avoids any changes and side-effects in other components or applications. This will save you a lot of time, effort, and a lot of headaches.

In conclusion be smart like your Adapter Pattern that you will be using, and make the ability to show your work and project to any interface without being held back from interface compatibility

Source: https://medium.com/@akshatsharma0610/adapter-design-pattern-in-java-fa20d6df25b8

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

Writing Good Documentation

Sources: Ángel Cereijo and GeeksForGeeks

Writing documentation for your project can be tedious and boring. Say you just finished your project, you published it, and you’re excited to see people use it… but they don’t know how. You need documentation to explain your project. 

Software documentation is the writing that goes along with your project, ranging from what your program does, how you plan to build the program, or any notes you may have for your team. There are four types of documentation: requirement, architectural, technical, and end-user. Requirement documentation explains the requirements for the program and how it should perform. Architectural documentation explains how the program should be structured and how processes should work with each other. Technical documentation explains the technical parts of the program, like the API and algorithms. End-user documentation explains how the software works for the user. 

Good documentation should be created throughout the development process. Saving it all until the end will burn you out and set you back. To prevent this, progress the documentation as you build the project. Split your project into smaller pieces, like how it is done in an Agile setting, and improve the documentation as new features are developed. 

Documentation should explain the purpose of the project as well. It should set up a problem that your program solves and why it is useful to solve the problem. Communicate with your team on how the problem is going to be solved and a plan to get there. Then, split the project up into tasks and assign them to the team members. Explain in detail any information needed for each task. Having the research and plan in writing makes it so anyone can complete the task at any time. As tasks are completed, update the documentation to the project before calling it completed. 

Having explanatory documentation also ensures that tests can be written easily, even without the actual code that is being tested. Then, as you write the code for that task, the tests are already completed and you can move on. 

As your team progresses through the project, your initial plan and process will probably change. With new resources and findings, the initial documentation needs to be updated as well. 

Once your project is published, your documentation is there to help the users easily use your program. It needs to be written in simple language for any reader and avoid ambiguity/unneeded repetition. 

Writing documentation is necessary for every project, helping to communicate with your development team and to serve as a guide to the users. It is important to write good documentation and keep in mind how other people will use it. Having the basics down of writing good documentation will help me in the future and give me a step up as a new software developer. 

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.