updated docs to official openapi specs not smartbear/swagger

Author: philsturgeon

openapi/frameworks/elysia.mdx

@@ -196,7 +196,7 @@ const app = new Elysia()
   .listen(3000);
 ```
 
-This configures the [root document object](https://swagger.io/specification/v3/#openapi-object) of the OpenAPI document.
+This configures the [root document object](https://spec.openapis.org/oas/v3.1.2.html#openapi-object) of the OpenAPI document.
 
 The `info` object is a required property used to add metadata about the API. The `externalDocs` object lets you extend your documentation by referencing an external resource.
 
@@ -243,7 +243,7 @@ const userInfo = t.Object(
 );
 ```
 
-The Elysia schema builder, `t`, gives compile-time and runtime type safety. It also registers the model as a reusable OpenAPI [Components Object](https://swagger.io/specification/v3/#components-object) schema, which you can see at the bottom of your OpenAPI document:
+The Elysia schema builder, `t`, gives compile-time and runtime type safety. It also registers the model as a reusable OpenAPI [Components Object](https://spec.openapis.org/oas/v3.1.2.html#components-object) schema, which you can see at the bottom of your OpenAPI document:
 
 ```json
 "components": {
@@ -357,7 +357,7 @@ responses: {
 },
 ```
 
-The [Responses Object](https://swagger.io/specification/#responses-object) is used to list the possible responses returned from the POST request. There is one possible response listed - a successful response. This response has a [`schema`](https://swagger.io/specification/#schema-object) that defines the content of the response. The `id` schema is referenced using [`$ref`](https://swagger.io/specification/#reference-object), the reference identifier that specifies the URI location of the value being referenced. Let's define this `id` model.
+The [Responses Object](https://spec.openapis.org/oas/v3.1.2.html#responses-object) is used to list the possible responses returned from the POST request. There is one possible response listed - a successful response. This response has a [`schema`](https://spec.openapis.org/oas/v3.1.2.html#schema-object) that defines the content of the response. The `id` schema is referenced using [`$ref`](https://spec.openapis.org/oas/v3.1.2.html#reference-object), the reference identifier that specifies the URI location of the value being referenced. Let's define this `id` model.
 
 Add the following `idObject` model to the `users.ts` file, below the `userInfo` model:
 
@@ -495,7 +495,7 @@ Add the following `tags` array to the configuration object of the `swagger` plug
   )
 ```
 
-This adds a `tags` array to the root OpenAPI document object. In the above code, we add metadata to the tag by passing in a [Tag Object](https://swagger.io/specification/#tag-object) (instead of a string) to the tag array item.
+This adds a `tags` array to the root OpenAPI document object. In the above code, we add metadata to the tag by passing in a [Tag Object](https://spec.openapis.org/oas/v3.1.2.html#tag-object) (instead of a string) to the tag array item.
 
 After adding tags to your routes, you'll see that they are organized by tags in Scalar:
 

openapi/frameworks/fastify.mdx

@@ -105,7 +105,7 @@ The option to output YAML is [brand new](https://github.com/fastify/fastify-cli/
 
 ## Supported OpenAPI Versions in Fastify and Speakeasy
 
-Fastify can generate OpenAPI specifications in [OpenAPI version 2.0](https://swagger.io/specification/v2/) (formerly known as _Swagger_) or [OpenAPI version 3.0.3](https://swagger.io/specification/v3/).
+Fastify can generate OpenAPI specifications in [OpenAPI version 2.0](https://spec.openapis.org/oas/v2.0.html) (formerly known as _Swagger_) or [OpenAPI version 3.0.3](https://spec.openapis.org/oas/v3.1.2.html).
 
 Speakeasy supports OpenAPI 3.x.
 

openapi/frameworks/nestjs.mdx

@@ -93,7 +93,7 @@ import { apiReference } from '@scalar/nestjs-api-reference';
 
 In the above code:
 
-- The `SwaggerModule.createDocument` method returns a serializable [OpenAPI document](https://swagger.io/specification/#openapi-document) object that we'll convert to an OpenAPI YAML document file using JS-YAML.
+- The `SwaggerModule.createDocument` method returns a serializable [OpenAPI document](https://spec.openapis.org/oas/v3.0.4.html#openapi-document) object that we'll convert to an OpenAPI YAML document file using JS-YAML.
 - We use `DocumentBuilder` to create the base structure of the OpenAPI document. The [`DocumentBuilder` methods](https://github.com/nestjs/swagger/blob/master/lib/document-builder.ts) set the properties that identify the purpose and owner of the document, such as the title and description properties.
 - We use the `createDocument()` method to define the API routes by passing in two arguments: the `app` instance and the document `config`. We can also provide a third argument, [`SwaggerDocumentOptions`](https://docs.nestjs.com/openapi/introduction#document-options).
 - We use `SwaggerModule.setup()` to expose the OpenAPI document at `/api-yaml` for the YAML format and `/api-json` for the JSON format.
@@ -168,7 +168,7 @@ Speakeasy currently supports the OpenAPI Specification versions 3.0.x and 3.1.x.
 
 ## Adding OpenAPI `info` in NestJS
 
-Let's improve the OpenAPI document by better describing it. We'll add more fields to the [info object](https://swagger.io/specification/#info-object), which contains metadata about the API.
+Let's improve the OpenAPI document by better describing it. We'll add more fields to the [info object](https://spec.openapis.org/oas/v3.0.4.html#info-object), which contains metadata about the API.
 
 Add the following `DocumentBuilder` methods to the `config` section of the document (`main.ts`) to supply more data about the API:
 
@@ -262,7 +262,7 @@ Add the following OpenAPI decorators to the `@Post()` route handler:
 @ApiBadRequestResponse({ description: 'Bad Request' })
 ```
 
-The `@ApiBody()` and `@ApiOkResponse` decorators use the [Schema Object](https://swagger.io/specification/#schemaObject), which defines the input and output data types. The allowed data types are defined by the `Cat` and `Dog` data transfer objects (DTO) schema. A DTO schema defines how data will be sent over the network.
+The `@ApiBody()` and `@ApiOkResponse` decorators use the [Schema Object](https://spec.openapis.org/oas/v3.0.4.html#schemaObject), which defines the input and output data types. The allowed data types are defined by the `Cat` and `Dog` data transfer objects (DTO) schema. A DTO schema defines how data will be sent over the network.
 
 Now, run the NestJS HTTP server and open `http://localhost:3000/api-yaml/`. You'll see the OpenAPI endpoints description is more fleshed out.
 
@@ -320,7 +320,7 @@ It should now look as follows:
         description: Forbidden
 ```
 
-The [Reference Object](https://swagger.io/specification/#reference-object) (`$ref`) is a reference identifier that specifies the location, as a URI, of the value being referenced. It references the `schemas` field of the [Components Object](https://swagger.io/specification/#components-object), which holds reusable schema objects.
+The [Reference Object](https://spec.openapis.org/oas/v3.0.4.html#reference-object) (`$ref`) is a reference identifier that specifies the location, as a URI, of the value being referenced. It references the `schemas` field of the [Components Object](https://spec.openapis.org/oas/v3.0.4.html#components-object), which holds reusable schema objects.
 
 If you look at the `components` schema, you'll see the `properties` objects are empty.
 

openapi/frameworks/rails.mdx

@@ -5,7 +5,7 @@ description: "Learn how to generate OpenAPI specifications for your Rails API us
 
 # How to generate OpenAPI documentation with RSwag for Rails APIs
 
-When building APIs with Ruby on Rails, clear and accurate documentation is essential for your API consumers. [The OpenAPI Specification](https://swagger.io/specification/) (formerly Swagger) has become the industry standard for documenting RESTful APIs. However, manually writing and maintaining OpenAPI documents can be a time-consuming and error-prone process.
+When building APIs with Ruby on Rails, clear and accurate documentation is essential for your API consumers. [The OpenAPI Specification](https://spec.openapis.org/oas/) has become the industry standard for documenting RESTful APIs. However, manually writing and maintaining OpenAPI documents can be a time-consuming and error-prone process.
 
 [RSwag](https://github.com/rswag/rswag) solves this problem by allowing you to generate OpenAPI documents directly from your RSpec tests. This ensures your documentation always stays in sync with your actual API implementation.