# Swagger Swagger is an open-source set of tools and an API description format for designing, building, documenting, testing, and consuming REST APIs. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The thoroughness of Tom Johnson's free Documenting API's course on OpenAPI 3.0 and Swagger UI DevFeed: [The thoroughness of Tom Johnson's free Documenting API's course on OpenAPI 3.0 and Swagger UI]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-09-09T21:17:32Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [OpenAPI Specification](), [Documentation](), [REST API](), [Swagger](), [Testing](), [Postman](), [JavaScript](), [JSON](), [Authentication](), [cURL](), [Chrome](), [Open Source]() Tags: [api](), [api-documentation](), [authentication](), [chrome](), [chrome-extension](), [curl](), [documentation](), [github](), [javascript](), [json](), [openapi](), [pdf](), [postman](), [rest-api](), [swagger](), [testing]() ### AI overview The article reviews Tom Johnson's free "Documenting APIs: A guide for technical writers and engineers" course. It describes the course's 17 chapters, practical API-learning exercises, coverage of REST APIs, OpenAPI, Swagger UI, testing and publishing API documentation, and a PDF edition exceeding 900 pages. ### Source excerpt While researching information for my job about the Swagger UI and how it can be used for testing, I came across this free course, called Documenting APIs: A guide for technical writers and engineers at https://idratherbewriting.com/learnapidoc/docapis_overview.html written by Tom Johnson, a technical writer based in Seattle who works for Google. The course looks intense, containing 17 chapters talking about Introduction to REST APIs, using APIs like a developer, Documenting API endpoints, the Open API spec, Testing API docs, Publishing API docs, and more. From the Course Introduction: "You'll first learn about API documentation by using a simple weather API to put a weather forecast on your site. [...] As you use the API, you'll learn about endpoints, parameters, data types, authentication, curl, JSON, the command line, Chrome's Developer Console, JavaScript, and more. The idea is that rather than learning about these concepts independent of any context, you learn them by immersing yourself in a real scenario while using an API. Immersion in real scenarios makes these tools and technologies more meaningful. "We'll then transition into standards, tools, and specifications for REST APIs. You'll learn about the required sections in API documentation, analyze examples of REST API documentation from various companies, learn how to join an open-source project to get experience, and more. "[...] We'll also dive into specifications such as the OpenAPI specification and Swagger UI (which provides tooling for the OpenAPI specification). Additionally, you'll learn how to document native library APIs and generate Javadoc". Tom Johnson offers a PDF version of this free course... over 900 pages, with more always being added. It also offers many workshop-like activities you could put in an actual itinerary. You would need for the course: Chrome, since it provides "a Javascript Console that works well for inspecting JSON", the JSON Formatter Chrome extension, Postman, a GitHub acco ## Testing the Swagger Petstore: Manually Testing An API Using Swagger UI DevFeed: [Testing the Swagger Petstore: Manually Testing An API Using Swagger UI]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-09-07T16:43:41Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Swagger](), [Testing](), [API](), [OpenAPI Specification]() Tags: [api](), [auth](), [authentication](), [authorization](), [http](), [openapi](), [payload](), [schema](), [swagger](), [testing](), [ui]() ### AI overview A practical guide to manually testing the Swagger Petstore API through Swagger UI. It covers happy-path, negative, boundary and edge-case, authentication and authorization, and contract and schema validation tests using the browser-based "Try it out" feature. ### Source excerpt With the last post, Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI we started exploring an API with Swagger UI, such as the Swagger Petstore at https://petstore3.swagger.io/ Here, we will start exploring how to test an API using the Swagger UI. The tests we can run are: Happy Path Testing, checking the Positive Scenarios Negative Testing, reviewing the Invalid Inputs & Error Handling Boundary & Edge Case Testing, checking how the API handles the extreme limits of allowed input ranges Authentication & Authorization Testing Contract and schema validation We can see in the Swagger PetStore there are three tag groups: Pet, Store, and User. Because this is a Swagger UI doc, we can perform manual testing using only the "Try it out" feature in Swagger UI. No external tools needed! Live HTTP requests can be executed directly from your browser. Types of Testing for the API Here are a few types of testing and examples you can do in Swagger UI Happy path Functional Testing Pet POST /pet: add a new pet with a complete, valid payload. Verify 200 and that the response echoes the submitted fields. PUT /pet: update the pet you just created. Verify the change persists on a follow-up GET. GET /pet/{petId}: retrieve the pet by the ID returned from the POST. GET /pet/findByStatus: query with each valid status value (available, pending, sold) individually. GET /pet/findByTags: query with a tag that exists on a pet you created. POST /pet/{petId} (form data): update name/status via form fields instead of JSON body. POST /pet/{petId}/uploadImage: upload a valid image file, verify response message and metadata. DELETE /pet/{petId}: delete a pet you created, then confirm GET on that ID now fails. Store POST /store/order: place an order with valid petId, quantity, shipDate, status. GET /store/order/{orderId}: retrieve the order just placed. GET /store/inventory: verify it returns a status-to-count map without needing auth. DELETE /store/orde ## Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI DevFeed: [Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-09-05T03:09:27Z Content type: article Language: en Sources: [T.J. Maher]() Topics: [OpenAPI Specification](), [Swagger](), [API](), [Documentation](), [Testing]() Tags: [api](), [api-documentation](), [openapi](), [swagger](), [testing]() ### AI overview This article reviews the Swagger Petstore test site and its API documentation formatted with OpenAPI 3.0 and Swagger UI. It also provides background on Swagger's origins, its acquisition by SmartBear, and the distinction between the OpenAPI Specification and SmartBear's Swagger toolset. ### Source excerpt For this next project, we will be examining the test site Swagger Petstore - OpenAPI 3.0 at https://petstore3.swagger.io/ https://petstore3.swagger.io/ If we wanted to really dive deep into creating API documentation, we could use: I'dRatherBeWriting's Free Documenting APIs course, showing an Introduction to REST APIs, using APIs like a developer, Documenting API endpoints, the Open API spec, Testing API docs, Publishing API docs, and more... ... But that goes too deep for this blog post. Before we begin, let's get into some background information. What is Swagger? According to OpenAPISpec.com's article, Who Created Swagger?, Swagger was created in 2010 by Tony Tam, the CTO of Wordnik, an online dictionary company that leveraged so many APIs, it was difficult for the six person engineering team to manage and scale them, writing API-clients and documentation by hand. After a 3 AM conversation, they thought... what if the API documentation could describe itself? There already was WADL, the XML-based Web Application Description Language. The name was coined after a joke they made, "Why WADL when you can Swagger?" Swagger went from being an internal fix for a company became to an open-source project other companies relied on. Swagger was acquired by SmartBear Software in 2015 from the renamed Wordnik, Reverb Technologies. According to OpenAPISpec's What Is the History of the SmartBear Swagger Acquisition Tony Tam also joined SmartBear as the VP of Products. Smartbear donated the Swagger Specification to a new group, the OpenAPI Initiative, sponsored by the Linux Foundation. I love SmartBear! They have hosted my old software testing Meetup, the now defunct Ministry of Testing - Boston many, many times. Since then: "OpenAPI" is the OpenAPI Specification as seen on GitHub "Swagger" is SmartBear's toolset such as Swagger UI, Swagger Editor, Swagger Codegen, and SwaggerHub (soon to be Swagger Studio). OpenAPI Initiative: Bridging Systems and Subcultures: A Swagger Origin Sto ## From Contributor to Outreachy Intern: My Fedora Journey Begins DevFeed: [From Contributor to Outreachy Intern: My Fedora Journey Begins]() Original publisher: [Read original article]() Author: Aman . Published: 2026-06-16T12:00:00Z Content type: article Language: en Sources: [Fedora Community Blog]() Topics: [Fedora](), [FastAPI](), [API](), [release engineering](), [Authentication](), [CI/CD](), [forgejo](), [Pydantic](), [Swagger](), [Deployment](), [openid]() Tags: [apis](), [backend](), [blog](), [fedora-project-community](), [intern](), [journey](), [mentored-projects](), [open-source](), [outreachy]() ### AI overview Aman describes his first two weeks as an Outreachy intern with the Fedora community. He introduces the Fedora Release Schedule Planner API project and outlines planned work on testing, CI reliability, OpenID Connect authentication, Fedora infrastructure integration, and deployment preparation. ### Source excerpt Introduction Hi, I'm Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others. I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have [...] The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog. ## Moving from Django DRF to Ninja API / Pydantic DevFeed: [Moving from Django DRF to Ninja API / Pydantic]() Original publisher: [Read original article]() Author: Michael Sidharta Published: 2025-11-10T05:35:43Z Content type: comparison Language: en Sources: [Kogan.com]() Topics: [Django](), [Pydantic](), [API](), [Python](), [Development](), [OpenAPI Specification](), [Swagger]() Tags: [api-documentation](), [data-validation](), [django](), [fastapi](), [python](), [swagger]() ### AI overview This article examines moving from Django REST Framework API patterns to Django Ninja API and Pydantic. It describes motivations including reducing boilerplate, improving performance for some use cases, using modern Python type hints and data validation, and enhancing developer experience. It also outlines Django Ninja's type-based validation, automatic OpenAPI documentation, performance focus, and simplified endpoint definitions. ### Source excerpt As our project grows, we're always looking for ways to streamline development, improve performance, and enhance the developer experience. Recently, we've been exploring a shift from our traditional Django REST Framework (DRF) API patterns to a combination of Django Ninja API and Pydantic. This blog post will delve into our motivations for this change, the benefits we've observed, and some considerations for others contemplating a similar transition. Why Consider a Change from Django DRF? Django REST Framework has been a robust and widely adopted solution for building APIs with Django. It provides a comprehensive set of tools, including serializers, viewsets, and excellent browser-based API interfaces. However, as our needs evolved, we identified areas where a different approach could offer advantages: Boilerplate Code: While DRF offers powerful abstractions, creating serializers, views, and viewsets can sometimes lead to a significant amount of boilerplate code, especially for simpler APIs. Performance: For certain use cases, the overhead of DRF's serializer validation and rendering can impact performance, particularly in high-throughput scenarios. Modern Python Features: We were keen to leverage modern Python features like type hints and data validation more extensively, which are core to Pydantic. Developer Experience: A more concise and explicit way to define API endpoints and data structures could improve developer productivity and reduce potential errors. Introducing Django Ninja API and PydanticDjango Ninja API Django Ninja is a web framework for building APIs with Django and Python 3.6+ type hints. It's heavily inspired by FastAPI and offers a number of compelling features: Type Hinting for API Endpoints: You define your request and response models using Pydantic, and Ninja automatically validates and serializes the data based on these type hints. Automatic OpenAPI (Swagger) Documentation: Just like FastAPI, Ninja generates interactive API documentation out o ## Should you generate docs from your API schema? DevFeed: [Should you generate docs from your API schema?]() Original publisher: [Read original article]() Author: Emma Adler Published: 2025-05-16T00:00:00Z Content type: tutorial Language: en Sources: [Mintlify Blog]() Topics: [Documentation](), [OpenAPI Specification](), [API](), [Structured-data](), [Swagger](), [JSON](), [YAML]() Tags: [ai-trends](), [api](), [api-documentation](), [automate](), [automation](), [best-practices](), [hybrid](), [json](), [openapi](), [schemas](), [swagger]() ### AI overview This guide examines the benefits and limitations of generating API documentation from OpenAPI schemas. It explains how schema-based tools such as Swagger UI automatically create documentation from structured endpoint, method, data model, and response definitions, while noting that automation can leave gaps in user guidance and conceptual explanations. It recommends combining automation with customization. ### Source excerpt When your API constantly changes, how do you ensure your documentation keeps up? ## Build Well-Documented and Authenticated APIs in Node.js with Fastify DevFeed: [Build Well-Documented and Authenticated APIs in Node.js with Fastify]() Original publisher: [Read original article]() Author: Julián Duque Published: 2024-04-29T23:25:00Z Content type: tutorial Language: en Sources: [Heroku]() Topics: [Fastify](), [API](), [Node.js](), [Authentication](), [JSON Web Tokens](), [OpenAPI Specification](), [Heroku](), [Postman](), [Swagger](), [Back end]() Tags: [apis](), [authentication](), [back-end](), [build](), [engineering](), [express](), [framework](), [heroku](), [how-to](), [javascript](), [jwt](), [node-js](), [openapi](), [postman](), [product-features](), [swagger]() ### AI overview A hands-on walkthrough for building a documented and authenticated API with Node.js and Fastify. It covers JWT authentication, Fastify Swagger plugins for generating an OpenAPI specification, Postman as an API client, and deployment to Heroku. ### Source excerpt If you're an API developer working with Node.js, then you're probably familiar with Express. But have you tried out the Fastify framework to build with power, speed, and convenience? In this walkthrough, we build a full-featured, easy-to-consume API with Fastify. And we deploy it to the cloud with ease. We show you how to: Get [...] The post Build Well-Documented and Authenticated APIs in Node.js with Fastify appeared first on Heroku. ## Results of Quick Testing of Documentation Tools' Accessibility DevFeed: [Results of Quick Testing of Documentation Tools' Accessibility]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2023-01-03T08:57:41.997000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Testing](), [Documentation](), [Swagger](), [Browser Extension](), [OpenAPI Specification](), [Document Object Model (DOM)]() Tags: [accessibility](), [automated](), [color](), [documentation](), [input](), [keyboard](), [openapi-specification](), [screen](), [swagger](), [testing]() ### AI overview This article reports quick accessibility testing of Swagger, Read the Docs, Docusaurus, and GitBook using the Axe browser extension, DOM inspection, and keyboard testing. The testing was not exhaustive because it did not include screen readers, narrower viewports, or zooming. For Swagger UI, Axe identified 64 issues, including color-contrast problems, form inputs without programmatically associated labels, and missing landmark regions. ### Source excerpt When writing my blog post about what backend devs can do for accessibility, I did some quick accessibility tests for different documentation tools. Initially, I thought I'd write about the results in that blog post, but there was just too much to report. So, I ended up writing this blog post. I chose four tools that I know many projects are using. These tools are: Swagger Read the Docs Docusaurus GitBook First, I ran an automated test with the aXe browser extension and dug deeper into the DOM based on the test results. After that, I tested the site with a keyboard. In this blog post, I'll share the test results and some thoughts about them. As you can see from the steps described above, the testing was not exhaustive. I just wanted to get an overview of the issues. I did not, for example, test with a screen reader or with narrower viewports (or zooming). This was a conscious decision, partly because I didn't have time and partly because this blog post would've been super long. And I think this already provides some overview of the state of accessibility of these tools. Let's get started. Swagger URL used for testing: https://petstore3.swagger.io/ Swagger is a set of tools used for API documentation. The Swagger API project started in 2011. Initially, it was a specification, but it was later named OpenAPI Specification. So it has a long history, and many projects use it. One of its tools is Swagger UI, a user interface for browsing the API endpoints. That's the one I'm testing for this blog post. Testing Swagger UI with Axe Runnin Axe-browser extension showed 64 issues, two of which are critical, 35 serious, 18 moderate, and 7 minor. Most of the issues (37) were related to color contrast issues. The contrast ratio for the problematic color combinations ranged between 2.03 and 3.75. Another problem was form input without programmatically associated labels. Some of them were flagged, but when I started digging deeper into the site's code, I noticed that not every insta ## Generate API documentation from Swagger on Ktor DevFeed: [Generate API documentation from Swagger on Ktor]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2022-03-22T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [Ktor](), [Swagger](), [OpenAPI Specification](), [API](), [Gradle](), [Documentation](), [backend-development]() Tags: [api](), [api-documentation](), [backend-development](), [documentation](), [gradle](), [how-to](), [ktor](), [openapi](), [swagger]() ### AI overview A tutorial on generating and exposing API documentation for a Ktor backend. It uses OpenAPI (Swagger) definitions, the Gradle Swagger Generator Plugin, ReDoc, and Ktor's static-content serving capabilities. ### Source excerpt SERIES: Building a backend with Ktor Part 1: Structuring a Ktor project Part 2: How to persist Ktor logs Part 3: How to use an in-memory database for testing on Ktor Part 4: How to handle database migrations with Liquibase on Ktor Part 5: Generate API documentation from Swagger on Ktor Part 6: How to schedule jobs with Quartz on Ktor Part 7: Moving from mobile to backend development with Ktor When a backend project exposes some APIs, there should also be a place where the clients of those APIs can see and understand what can be consumed. This place can be a document, a text file, a website, etc. ## Working with OpenAPI contract in multiple files DevFeed: [Working with OpenAPI contract in multiple files]() Original publisher: [Read original article]() Published: 2020-04-23T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [OpenAPI Specification](), [Swagger](), [API]() Tags: [api](), [code](), [download](), [editor](), [embedded](), [github-issues](), [openapi](), [openapi-specification](), [swagger]() ### AI overview This tutorial explains how to split a large OpenAPI specification into multiple files and work with external references. It discusses Swagger Editor's limitations, Stoplight Studio, swagger-ui-watcher, and a workflow for organizing a pet store API across separate files. ### Source excerpt Real-life OpenAPI specification files tend to go really big really fast. In this post, I'll try to explore how we can split single specification file into multiple files and don't get crazy while scrolling up and down like a mad man. Read more ## Validating OAS 3 specification in your CI build DevFeed: [Validating OAS 3 specification in your CI build]() Original publisher: [Read original article]() Published: 2019-02-15T17:29:41Z Content type: tutorial Language: en Sources: [Miro Cupak]() Topics: [OpenAPI Specification](), [Continuous integration](), [YAML](), [GitHub](), [Swagger](), [Testing](), [pull-requests]() Tags: [ci](), [continuous-integration](), [github](), [openapi](), [pull-requests](), [specifications](), [swagger](), [swagger-validator-badge](), [testing](), [travis](), [travis-ci](), [yaml]() ### AI overview This tutorial explains how to validate an OpenAPI 3 specification on every pull request as part of continuous integration. It uses the Swagger Validator Badge tool in Travis CI, building version 2.0.0 locally because hosted support for OpenAPI 3 was incomplete at the time of writing. ### Source excerpt As part of my work on standards under GA4GH, I frequently deal with API specifications, most often written in OpenAPI 3 (OAS 3). The setup is always similar - there's a public GitHub repository containing an OAS 3 YAML file and a few common auxiliary files (.gitignore, LICENSE, CONTRIBUTING.md, and README.md). Reference implementations of...