Merge branch 'develop' into jason/review

* develop:
  Update send-http-requests.md
  Update overview.md
  Update run-test-terminal.md

articles/desktop/overview.md

@@ -21,3 +21,13 @@ When you start the Stoplight desktop app, it will start an instance of Prism on
 
 * The Stoplight desktop app can read/write specification files on your local file system. This is perfect for generating specification outside of Stoplight (like from code), want to use version control systems like Git, or want to use your favorite IDE to work on a spec. 
 * This feature is **NOT** available in the web app 
+
+
+
+
+ the web app 
+
+
+<!--stackedit_data:
+eyJoaXN0b3J5IjpbMTU3NDc5MjY0XX0=
+-->

articles/hubs/publishing.md

@@ -1,32 +1 @@
-# Publishing 
 
-## What 
-
-Publishing your documentation has never been easier. Stoplight has added: 
-- New **Integrations** for Segment, Intercom, and Google Analytics to allow for traffic monitoring and additional analytics 
-- New **Authorizations** to make sure your documentation is secure at all times. This includes basic user/password authentication and SSO provider integration, powered by Auth0, SAML, and more.
-- New **Builds** section for tracking published Hubs, including when a Hub was published, who published it, and under what domain.
-
-Take that Gutenberg! 
-
-## Who 
-
-- **Organization Owners**, **Account Owners**, and **Administrators** can publish Hubs 
-
-## How 
-
-1. From the Stoplight editor, click on **Publish** in the far left-hand toolbar 
-2. Input a **subdomain** under Stoplight's tech-docs.io domain
-    - Or input a **custom domain** (optional)
-3. Once completed, click **Next ->** 
-4. Select the Hub you wish to publish under **Hub File**
-5. Add Integrations to **Segment**, **Intercom**, and **Google Analytics** under Integrations (optional)
-6. Add security via **Username/Passwords Login**, **Auth0**, or **SAML** (optional) 
-7. Once completed, click **Publish** in the top left
-8. A confirmation window will ask you to confirm your selection, click **Okay**
-9. Once confirmed, **Build Logs** will display your current progress 
-    - The process usually takes 2-5 minutes 
-10. Once the process has completed, a **green success message** will display at the bottom of the screen, letting you know that the Hub was published succesfully 
-11. Once a Hub is published, it will appear under **Builds** 
-12. To unpublish a Hub, select **Unpublish** in the **Danger Zone** underneath **Builds**
-    - If you wish to delete all builds and release the domain you are currently using, select **Remove Domain**

articles/modeling/object-inheritance.md

@@ -1,143 +1,38 @@
-# Object Inheritance
+# Object Inheritance 
 
-## What
+## What 
+- A **model** contains common resuable information that can be referenced in your endpoint definitions or other models in your API design. 
+- When a model derives its properties from another model, the event is called **inheritance**. 
+- The model which contains the common set of properties and fields becomes a parent to other models, and it is called the **base type**.
+- The model which inherits the common set of properties and fields is known as the **derived type**.
+- If a base type inherits its properties from another model, the derived type automatically inherits the same properties indicating that inheritance is **transitive**. 
+- OpenAPI Specification v2 uses the **allOf** syntax to declare inheritance. 
+- **allOf** obtains a collection of object definitions validated independently but, collectively make up a single object. 
 
-* A **model** contains properties that can be reused and referenced by endpoint
-  definitions, shared objects, and other models. For more information on what
-  models are and how they can be used, please see the API model overview
-  [here](./api-models.md).
+## Why 
+- Inheritance makes your API design more compact. It helps avoid duplication of common properties and fields. 
 
-* **Inheritance** is when a model derives its properties from another model.
+## Best Practices 
 
-* When a model inherits properties from another model, the model being inherited from is
-  known as a **base type** (or parent). A model that is inheriting
-  properties from a base type is known as a **derived type** (or child).
+<!-- theme: info --> 
+> Avoid using contradictory declarations such as declaring properties with the samer name but dissimilar data type in your base model and derived model. 
 
-* When a base type inherits properties from another model, any derived types
-  will also automatically inherit the properties as well. For example, if model
-  C is a derived type of model B, and model B is a derived type of model A, then
-  model C is also a derived type of model A. In mathematics, this is known as
-  the [transitive property](https://en.wikipedia.org/wiki/Transitive_relation).
+### Example 
 
-* To specify that a model should inherit from a base type, use the **allOf**
-  option (under "Combination Types") when building the model. By specifying
-  allOf and referencing the base type, the model will automatically inherit all
-  of the parent model's properties. A model can also inherit from multiple base
-  types as needed.
-
-## Why
-
-* Inheritance makes your API design more compact. It helps avoid duplication of
-  common properties and fields, reducing the complexity of the specification and the chance of errors.
-
-## Best Practices
-
-<!-- theme: info -->
-
-> Avoid using contradictory declarations such as declaring properties with the
-> same name but dissimilar data type in your base model and derived model.
-
-### Example
-
-As an example, imagine you are creating an API that stores and categorizes
-different types of vehicles. To begin working on the API, you will need a base
-"car" model with a few attributes that are common across all vehicles. This
-might look similar to:
-
-```javascript
-// the car base type
+```
 {
-  "type": "object",
-  "properties": {
-    // number of wheels
-    "wheels": {
-      "type": "integer"
-    },
-    // number of doors
-    "doors": {
-      "type": "integer"
-    },
-    // brand of car
-    "make": {
-      "type": "string"
-    },
-    // model of car
-    "model": {
-      "type": "string"
-    }
-  }
+  Vehicle: 
+    type: object
+    properties: 
+      brand: 
+        type: string 
+  Sedan: 
+    allOf: # (This keyword combines the Vehicle model and the Sedan model) 
+      $ref: '#/definitions/Vehicle'
+      type: object
+      properties: 
+        isNew:
+          type: boolean
 }
 ```
 
-<!--FIXME Insert image of creating model from UI -->
-
-Now that we have a base type model, we now need a derived type that extends the
-base type. Since we're dealing with cars, let's create a model that defines a
-SUV type (or a Sport Utility Vehicle):
-
-```javascript
-// the SUV model
-{
-  "allOf": [
-    // a reference to the car base type
-    {
-      "$ref": "#/definitions/car"
-    },
-    // properties that are only applied to the SUV model
-    {
-      "type": "object",
-      "properties": {
-        // whether the vehicle can go "off road"
-        "off-road": {
-          "type": "boolean"
-        },
-        // the amount of ground clearance
-        "ground-clearance": {
-          "type": "integer"
-        }
-      }
-    }
-  ]
-}
-```
-
-<!--FIXME Insert image of creating derived model in UI -->
-
-As shown above, by wrapping our SUV model inside of an `allOf` block, we are
-able to include all of the properties that are included in the car base model
-above.
-
-When fully de-referenced (the car reference is replaced with the car
-properties), the derived SUV model will have the following JSON properties:
-
-```javascript
-{
-  "type": "object",
-  "properties": {
-    // number of wheels
-    "wheels": {
-      "type": "integer"
-    },
-    // number of doors
-    "doors": {
-      "type": "integer"
-    },
-    // brand of car
-    "make": {
-      "type": "string"
-    },
-    // model of car
-    "model": {
-      "type": "string"
-    },
-    // whether the vehicle can go "off road"
-    "off-road": {
-      "type": "boolean"
-    },
-    // the amount of ground clearance
-    "ground-clearance": {
-      "type": "integer"
-    }
-  }
-}
-```

articles/modeling/polymorphic-objects.md

@@ -0,0 +1,42 @@
+# Polymorphic Objects
+
+## What
+
+* Resources in your API are polymorphic. They can be returned as XML or JSON and can have a flexible amount of fields. You can also have requests and responses in your API design that can be depicted by a number of alternative schemas.
+* **Polymorphism** is the capacity to present the same interface for differing underlying forms.
+* The **discriminator** keyword is used to designate the name of the property that decides which schema definition validates the structure of the model.
+
+## Why
+
+* Polymorphism permits combining and extending model definitions.
+
+## Best Practices
+
+<!-- theme: warning -->
+
+> The discriminator property **must** be a mandatory or required field. When it is used, the value **must** be the name of the schema or any schema that inherits it.
+
+### Example
+
+```yaml
+definitions:
+  Vehicle:
+    type: object,
+    discriminator: model
+    properties:
+      model:
+        type: string
+      color:
+        type: string
+    required:
+      -model
+  Sedan: # If Vehicle.model is Sedan then use Sedan model for validation.
+    allOf:
+      - $ref: '#/definitions/Vehicle'
+      - type: object
+          properties:
+            dateManufactured:
+              type: date
+          required:
+            - dateManufactured
+```

articles/modeling/shared-params-responses.md

@@ -1,194 +1 @@
-# Shared Parameters and Responses
 
-While designing API's in Stoplight, it is common to have multiple endpoints
-share a set of query parameters and API responses. To help reduce extra
-work (and the chance of introducing errors), it is important to: 
-
-* Identify endpoints with common parameters 
-* Use _shared components_ to reference the same property multiple times instead
-  of rewriting the properties for each individual endpoint.
-
-Shared components in Stoplight come in two forms:
-
-* __Parameters__ - These are shared parameters that can be applied to requests
-  across multiple endpoints.
-
-* __Responses__ - These are shared response objects that can be applied to
-  multiple endpoints.
-
-## Parameters
-
-Shared parameters provide a way to use request properties across multiple API
-endpoints without having to duplicate effort.
-
-![](../../assets/gifs/shared-params-responses-param.gif)
-
-Shared parameters are supported in the following request property locations:
-
-  * __path__ - The request URL path
-  * __query__ - The request URL query string
-  * __header__ - The request HTTP Header field object
-  * __body__ - The request HTTP message body
-  * __form-data__ - The request HTTP message body in the `multipart/form-data` format 
-
-<!-- theme: info -->
-> For more information the above properties, see the [OpenAPI v2 Specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameter-object)
-
-Similar to generic request parameters, restrictions on the parameter values can
-also be applied based on type, expected default value, minimum/maximum length,
-and regular expression (regex).
-
-![](../../assets/images/shared-params-responses.png)
-
-To use a shared parameter, navigate to an API endpoint's _Request_ section and
-create a reference to the shared parameter using the "chain" button as shown in
-the image above. Once the parameter has been referenced, any updates to the
-shared parameter will automatically be propagated to every endpoint using that
-parameter.
-
-![](../../assets/gifs/shared-params-responses-param2.gif)
-
-Like other references in Stoplight, shared parameters can also be shared across
-files, projects, and other external sources.
-
-### Shared Parameters Example
-
-Let's say you are creating an API to serve thousands of cooking recipes. When dealing with large volumes of
-data, you typically want to avoid sending _all_ data in a request. To help avoid
-sending more data than is necessary, most applications implement a "paging"
-feature that allows clients to retrieve a small portion of results (i.e. a single
-page).
-
-There are multiple ways to approach a paging feature. For this example, we
-want to add two query string parameters to every request:
-
-* `limit` - The number of results to return when viewing a page. For example,
-  setting `limit` to `20` means that, at most, 20 results will be returned in the
-  request.
-* `offset` - The number of results to skip before returning results. For
-  example, setting an `offset` of `20` means that the API will discard the first
-  20 results.
-
-By using the two parameters above, a client can efficiently "page" through
-results, only returning items that are within the requested bounds. To demonstrate, let's use the parameters to display the first page of our recipe
-results:
-
-```
-GET /recipes?limit=20&offset=0
-```
-
-Since the `offset` is set to `0`, the API will not discard any results. Paired
-with a `limit` of `20`, we will only see the first 20 results (1 through 20). 
-
-To view the second page of recipes, we would use:
-
-```
-GET /recipes?limit=20&offset=20
-```
-
-By setting an `offset` of `20`, the API will discard the first 20 results. Paired
-again with a `limit` of `20`, we will see the second page of results (21 through
-40).
-
-### How
-Now that we know how we want the components to behave, let's create them in
-Stoplight. To get started, create a new shared parameter for an OpenAPI file
-under the "Shared" section of the menu.
-
-![](../../assets/images/shared-params-responses2.png)
-
-As shown in the image above, set the properties for each parameter based on our
-requirements:
-
-1. Be sure to set the display names for both components properly. In our
-   example, we only have two parameters, however, if there are multiple shared
-   parameters with similar names, you may want to set a more descriptive name
-   (i.e. 'recipe-limit' instead of 'limit').
-2. Since both components are query string parameters, set the property location
-   for each as 'query'.
-3. Set the name of the parameter, which is how it will be set in HTTP requests.
-4. Optional type restrictions can be applied to the values. In our case, since
-   both parameters are integer values, we can use the 'integer' format
-   restriction.
-5. Setting a default value can be useful if you don't need the client to specify
-   each parameter for every request. For our example, it makes sense to set
-   defaults that will return the first page (limit of 20, offset of 0).
-
-![](../../assets/images/shared-params-responses3.png)
-
-Once the shared parameters are created, reference them in any API endpoint under the
-__Query Parameters__ block of the request section in the editor.
-
-## Shared Responses
-
-Shared responses provide a practical way to re-use response objects across multiple API
-endpoints without having to duplicate effort. Similar to the shared components
-discussed above, shared responses allow you to reference a single response
-multiple times without having to recreate each response manually. The added
-benefit of this approach is that updates to the shared response object are
-automatically propagated to any endpoint using that object, no extra changes
-required.
-
-![](../../assets/gifs/shared-params-responses-response.gif)
-
-Shared responses allow you to configure the following properties:
-
-* Headers - Customize the HTTP Headers returned in the response
-* Response body - Customize the HTTP message body contents using the Stoplight
-  modeling tool (or reference a pre-existing model)
-
-<!-- theme: info -->
-> For more information on the above properties, see the OpenAPI v2 Specification
-  [here](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#responseObject)
-
-![](../../assets/gifs/shared-params-responses-response2.gif)
-
-To use a shared response, navigate to an API endpoint's __Response__ section and
-create a reference to the shared response by choosing the _Type_ of the response
-as "Reference". Once the Response type is set to "Reference", you can then
-choose the shared response to use for that endpoint. Shared responses can also
-be shared across files, projects, and other external sources.
-
-### Shared Responses Example
-
-Let's say you have a set of
-API endpoints that should return the same error response when a failure occurs.
-Every time an error is returned from the API, you want to make sure the
-following properties are returned:
-
-* `error_message` - A descriptive error message about the failure in string format.
-* `error_code` - A code representing the category of the failure in integer format.
-* `tracking_id` - A tracking ID that can be used by the caller to follow-up with
-  an administrator for more information (ie, debug an issue with customer
-  support).
-
-Now that we know what should be returned, let's create a shared response in
-Stoplight. To get started, create a new shared response for an OpenAPI file
-under the "Shared" section of the menu.
-
-![](../../assets/images/shared-params-responses4.png)
-
-As shown in the image above, set the properties for each portion of the response
-based on our requirements:
-
-1. Set the name of the shared response. In our example, we only have one error
-   type, however, if there are multiple error responses with similar names, you
-   may want to set a more descriptive name (ie, 'api-tracking-error' instead of
-   'error').
-2. A short description of the error response, such as why it is needed and how
-   it is used.
-3. The contents of the shared response object based on the three required
-   properties above.
-
-![](../../assets/images/shared-params-responses5.png)
-
-Once the shared response is created, it can be referenced in any API endpoint by
-using a _Reference_ type under a response. A shared response can also be used
-multiple times under the same endpoint.
-
-***
-
-**Related**
-
-* [OpenAPI v2 Parameter Objects Reference](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameter-object)
-* [OpenAPI v2 Response Objects Reference](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#responseObject)

articles/testing/assertions.md

@@ -0,0 +1,30 @@
+# Assertions 
+
+## What is an Assertion? 
+
+- An API test consists of a series of steps (these are sometimes HTTP requests) that can be executed collectively or individually.
+- An **assertion** is a specification that indicates the expected outcome (response) to a request executed in a test. 
+- A test is unsuccesful if an assertion fails i.e. the actual outcome is not equal to the expected outcome
+- You can create assertions for status codes, response time, reponse content, header values, etc. 
+- When you execute an assertion, you can determine the type of operation you want to perform with your expected outcomes. 
+
+### Comparison Logic Available in Scenarios 
+- equals 
+- greater than 
+- greater than or equals 
+- less than 
+- less than or equals 
+- no equal 
+- exists
+- length equals 
+- contains 
+- validate pass 
+- validate fail 
+
+## Why
+- Assertions are checked any time a test is executed. 
+- Assertions are used to detemine the state of a test (pass or fail). 
+- Assertions are ideal for discovering if an API satisfies stipulated objectives. 
+
+## Assertions in Scenarios 
+- Scenarios in Stoplight are grouped into collections. To create an assertion for a step in Scenarios, you need to create a collection and add your Scenarios to it. 

articles/testing/authorization.md

@@ -0,0 +1,20 @@
+# Authorization 
+
+## What is Authorization? 
+ 
+- **Authentication** is the process of verifying if a user or API consumer can have access to an API. 
+- **Authorization** defines the resources an authenticated (properly identified) user can access. For example, a user might be authorized to use an endpoint for retrieving results but denied access to the endpoint for updating a data store. 
+- Authentication strategies can be implemented using basic HTTP authentication or OAuth methods. Authorization can be implemented using roles and claims. 
+
+## Authentication Schemes 
+- **Basic Authentication** is easy to implement and utilizes HTTP headers to validate API consumers. While the credentials might be encoded, they are not encrypted. It is advisable to use this method over HTTPS/SSL. 
+- **OAuth 1.0** has its foundation in cryptography. Digital signatures are used to authenticate and ensure the data originates from an expected source. It can be used with or without SSL. 
+- While OAuth 1.0 works primarily with web clients, **OAuth 2.0** works with web and non-web clients. OAuth 2.0 is easy to implement and focuses on bearer tokens. It wokrs with HTTPS/SSL for its security requirement. 
+- **AWS Signature** is a secutiry protocol that defines authentication information added to AWS requests. It consists of an access key ID and a security access key. Users who generate manual HTTP requests to AWS are required to sign the requests using AWS Signature. [Click here to learn more about AWS Signature](https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html)
+
+## Best Practices for Authentication and Authorization when Testing APIs
+
+- Use the same authentication and authorization your users would use during testing. Doing so will help you effectively identify and resolve issues users might face in a live scenario. 
+- Avoid creating too many test accounts with administrative access to all endpoints and resources during your test phase. It can be exploited, putting your resources and data at risk when the API is avaialble to consumers. 
+- Use ecryption to store valid IDs and credentials. Ensure test procedures containing valid user IDs or tokens are not displayed as unmasked text in test results or test logs. 
+- Test your authentication and authorization procedures rigorously by attempting to access secured resources with invalid credentials or session tokens or by atttempting to access a resource denied to an authenticated user. 

size.sh

@@ -1,34 +0,0 @@
-#!/bin/bash
-#set -x 
-
-# Shows you the largest objects in your repo's pack file.
-# Written for osx.
-#
-# @see https://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
-# @author Antony Stubbs
-
-# set the internal field spereator to line break, so that we can iterate easily over the verify-pack output
-IFS=$'\n';
-
-# list all objects including their size, sort by size, take top 10
-objects=`git verify-pack -v .git/objects/pack/pack-*.idx | grep -v chain | sort -k3nr | head`
-
-echo "All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file."
-
-output="size,pack,SHA,location"
-allObjects=`git rev-list --all --objects`
-for y in $objects
-do
-	    # extract the size in bytes
-	        size=$((`echo $y | cut -f 5 -d ' '`/1024))
-		    # extract the compressed size in bytes
-		        compressedSize=$((`echo $y | cut -f 6 -d ' '`/1024))
-			    # extract the SHA
-			        sha=`echo $y | cut -f 1 -d ' '`
-				    # find the objects location in the repository tree
-				        other=`echo "${allObjects}" | grep $sha`
-					    #lineBreak=`echo -e "\n"`
-					        output="${output}\n${size},${compressedSize},${other}"
-					done
-
-					echo -e $output | column -t -s ', '