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

@@ -7,7 +7,7 @@ description: "Learn how to generate OpenAPI specifications for your Rails App us
 
 When building APIs in a Ruby on Rails application, "Convention over Configuration" is already embraced. Building RESTful routes is standard for most Rails developers, as is writing tests using Test Driven Development (TDD), but creating an OpenAPI document that accurately describes an API can be another matter.
 
-[The OpenAPI Specification](https://swagger.io/specification/) (formerly Swagger) has become the industry standard for documenting RESTful APIs, but manually writing and maintaining OpenAPI documents can be a time-consuming and error-prone process.
+[The OpenAPI Specification](https://spec.openapis.org/oas/) has become the industry standard for documenting RESTful APIs, but 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 enabling OpenAPI documents to be generated directly from RSpec tests. This approach helps documentation stay in sync with the actual API implementation.