Swagger Spec -> OpenAPI Spec

Author: webron

docs/adding-paths.md

@@ -51,7 +51,7 @@ The parts of the path definition include:
 
 * `parameters:` specifies any parameters used by the path. They can be passed as query or form parameters, or headers. 
 
-* The other keys conform to the Swagger 2.0 [specifications](https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md). The parameters is a YAML array that defines all the parameters required for the call. The responses object defines the response specifications for response codes.
+* The other keys conform to the Swagger 2.0 [specifications](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md). The parameters is a YAML array that defines all the parameters required for the call. The responses object defines the response specifications for response codes.
 
 ### <a name="more"></a>More about route handling
 
@@ -93,7 +93,7 @@ When you call your API, the middleware attempts to match a route defined in the
 
 ### <a name="models"></a>Request and response models
 
-The Swagger specification allows you to define both request and the response models (also called schemas). The `path` definition described in the previous section is an example of a request model. 
+The OpenAPI Specification allows you to define both request and the response models (also called schemas). The `path` definition described in the previous section is an example of a request model. 
 
 Here's an example of a weather API that returns a relatively complex object.
 

docs/cli.md

@@ -141,7 +141,7 @@ Example:
 
 ##### <a name="docs"></a>swagger docs
 
-Opens the Swagger 2.0 specification in your browser. 
+Opens the OpenAPI 2.0 Specification in your browser. 
 
 Example:
 

docs/introduction.md

@@ -7,7 +7,7 @@ The swagger module provides tools for designing and building APIs entirely in No
 ### <a name="sdlc"></a>The API-First Development Process
 API design is a discovery process. Swagger development begins with design tooling, and it expects that you will evolve your interface over time. It gracefully handles the routing of interfaces to controllers so that you can make changes to your interfaces without clobbering any of your implementation logic.
 
-Designing an API specification is like writing a contract. As you write the spec in YAML using [Swagger 2.0](https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md), your API documentation is generated in real-time, allowing the client and server teams to agree on how their systems will work together. 
+Designing an API specification is like writing a contract. As you write the spec in YAML using [Swagger 2.0](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md), your API documentation is generated in real-time, allowing the client and server teams to agree on how their systems will work together. 
 
 Once you have defined your first operation, it drives a mock server, which enables  client development happen in parallel with server development. As you build the client, you will discover further changes you'll need to make to your APIs, meaning another iteration of the specification.
 

docs/mock-mode.md

@@ -252,7 +252,7 @@ Here's an example that returns some data whenever the `search()` handler method
 
 After you're happy with your API design, you're ready to implement wire up the controller for the `/weather` path. 
 
-You simply specify in the Swagger spec the route handler (controller) file, which method to call in the controller (operationId), and any query parameters you wish to pass: 
+You simply specify in the OpenAPI spec the route handler (controller) file, which method to call in the controller (operationId), and any query parameters you wish to pass: 
 
 In weather sample's `swagger.yaml` file, it looks like this:
 

docs/quick-start.md

@@ -50,7 +50,7 @@ That's it - You have now created, started and tested your first API project with
 
 Open <project-root>/app.js in an editor. This is the main Node.js app that installs middleware and requires the API framework that you chose when you created your project.
 
-The middleware modules perform tasks like Swagger specification validation and endpoint routing. For more information, see [swagger modules and dependencies](./modules.md).
+The middleware modules perform tasks like OpenAPI Specification validation and endpoint routing. For more information, see [swagger modules and dependencies](./modules.md).
 
 ### <a name="openeditor"></a>Open the Swagger editor
 

docs/swagger-about.md

@@ -20,7 +20,7 @@ To read more about Swagger, refer to:
 
 The Swagger Editor lets you design your API specification and preview its documentation for your swagger API. The editor is installed with swagger.
 
-A swagger.yaml file is installed into  every new swagger project, and lives in `<project_root>/api/swagger/swagger.yaml`. It conforms to the [Swagger 2.0 specification](https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md).  
+A swagger.yaml file is installed into  every new swagger project, and lives in `<project_root>/api/swagger/swagger.yaml`. It conforms to the [OpenAPI 2.0 Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md).  
 
 Behind the scenes, Swagger middleware validates and processes the Swagger configuration file, and routes API operation endpoints to controller files. All **you** need to do is implement your custom API controller logic. 
 
@@ -44,4 +44,4 @@ YAML is intended to be easy for humans to read. Every swagger project includes a
 
 ### <a name="nextstep"></a>Next step
 
-For a more detailed look the Swagger configurations, see "[The Swagger specification file](./swagger-file.md)".
+For a more detailed look the Swagger configurations, see "[The OpenAPI Specification file](./swagger-file.md)".

docs/swagger-file.md

@@ -1,12 +1,12 @@
-## <a name="understandingthespec"></a>Understanding the Swagger specification file
+## <a name="understandingthespec"></a>Understanding the OpenAPI Specification file
 
 * [Intro](#intro)
 * [Default swagger project file](#default)
-* [Swagger specification elements](#reference)
+* [OpenAPI Specification elements](#reference)
 
 ### <a name="intro"></a>Intro
 
-When you execute `swagger project create myproject`, a default Swagger model is placed in `myproject/api/swagger/swagger.yaml`. This model conforms to the [Swagger 2.0 specification](https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md). 
+When you execute `swagger project create myproject`, a default Swagger model is placed in `myproject/api/swagger/swagger.yaml`. This model conforms to the [OpenAPI 2.0 Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md). 
 
 >Note: For a quick intro to swagger, see "[What is Swagger](./swagger-about.md)". 
 
@@ -56,13 +56,13 @@ Here is the entire `swagger.yaml` file that is provisioned for a new swagger pro
 ```
 
 
-###<a name="reference"></a>Swagger specification elements
+###<a name="reference"></a>OpenAPI Specification elements
 
-The Swagger file includes a number of standard Swagger 2.0 specification elements. You can read about them in the [Swagger 2.0 specification](https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md). 
+The Swagger file includes a number of standard OpenAPI 2.0 Specification elements. You can read about them in the [OpenAPI 2.0 Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md). 
 
 Here's a brief description of the elements in a swagger project file:
 
-*  **swagger: 2.0** - (Required) Identifies the version of the Swagger specification (2.0).
+*  **swagger: 2.0** - (Required) Identifies the version of the OpenAPI Specification (2.0).
 
 *  **info:** - (Required) Provides metadata about the API.
 
@@ -76,7 +76,7 @@ Here's a brief description of the elements in a swagger project file:
 
 *  **produces:** - (Optional) A list of MIME types the APIs can produce.
 
-*  **paths:** - (Required) Defines the available operations on the API. You'll spend most of your time configuring the paths part of the file. You can read about the path element in the [Swagger 2.0 specification](https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md). In general, the paths section specifies an operation's verb (like `get`), the endpoint for an API operation (like `/hello`), query parameters, and responses. 
+*  **paths:** - (Required) Defines the available operations on the API. You'll spend most of your time configuring the paths part of the file. You can read about the path element in the [OpenAPI 2.0 Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md). In general, the paths section specifies an operation's verb (like `get`), the endpoint for an API operation (like `/hello`), query parameters, and responses. 
 
 * **definitions:** - (Optional) These represent the structure of complex objects such as request and response bodies. For example, you might have a collection of `/users` that returns an array of `user` objects. You would describe these with two definitions: 1) to describe the `User` object, and 2) the definition of the `Users` array. Swagger uses [JSON-schema](http://json-schema.org/).