Update glossary.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/glossary.md

@@ -0,0 +1,300 @@
+# Glossary 
+
+## General Terms 
+
+**Reference**: References allow you to link a value to another object's value such that updating the "referenced" value updates the linked value simultaneously. References are especially useful when trying to avoid duplication of work, since objects in Stoplight can be re-used multiple times. References can be created for objects in the current project, another project, or even by external URL
+
+**Headers**: Carries information between a client and a server during a Request or a Response
+
+**minLength**: An attribute used to constrain the length of a string. The length of a string instance must not be less that the minLength when used 
+
+**maxLength**: The length of a string instance must not exceed maxLength when used 
+
+**Pattern**: Indicates that a string should be a valid regular expression
+
+**Allow empty value**: Indicates if an empty value is acceptable
+
+**Enum**: List of allowed values 
+
+**Body**: Data transferred in HTTP message following the Header
+
+**Validation**: A linter that checks the accuracy of JSON files and/or data
+
+**API key**: A special token used to indicate the origin of a request 
+
+**Metadata**: Data that describes and gives information about data
+
+**String**: Double-quoted Unicode characters
+
+**Array**: An ordered sequence of values
+
+**Object**: An unordered collection of key-value pairs. Objects in JSON are surrounded by curly braces {}
+
+**Integer**: Digits from 0-9. Can be negative or positive
+
+**Boolean**: True or False 
+
+**Null**: A data type that indicates an empty value. Supported by JSON
+
+**Response Codes**: Otherwise known as 'HTTP status codes', these are issued by a server in response to a client's request made to the server
+
+### Authorization 
+
+**Basic Auth**: An authentication scheme that utilizes HTTP headers to validate API consumers. Utilizes Base64 encoding 
+
+**Digest Auth**: Similar to Basic Authentication, but applies a hash function to encrypt the username and password before sending them over the network
+
+**OAuth 1.0**: OAuth 1.0 makes use of digital signatures to authenticate and ensure the data originates from an expected source. It can be used with or without SSL
+
+**OAuth 2.0**: OAuth 2.0 authentication scheme expands upon 1.0 with a concentration on bearer tokens. It works with HTTPS/SSL for its security requirements
+
+**AWS Signature**: A digital security signature included in the authentication information send in a request. It is used by Amazon Web Services (AWS) to verify the identity of the requestor
+
+## General Platform 
+
+**Organizations**: Organizations function as a shared space for you and your co-workers. Organizations are ideal for grouping people, data, and billing together in one convenient location
+
+**Teams**: A Team is a collection of people with common interests. Teams make it easier for Organization Members to collaborate and allow you to have additional control over permissions 
+
+**Project**: A Project is the workspace of the Stoplight Platform 
+
+**Lifecycle Tags**: These tags help you effectively organize the various stages of your API development process 
+
+**Change Log**: Record of all significant changes made to a Project 
+
+**Project Private/Public**: Describes the visibility status of a Project. A Public Project can be viewed by anyone, when a Project is Private, the Project Owner determines who can view the Project
+
+## Editors 
+
+**Tokens**: Unique identifier used to authenticate a consumer or application requesting access to an API
+
+**API Reference**: Documentation containing what you need to know to use or work with an API
+
+**HTTP Request Maker**: Utility used to make a request to an API endpoint, returning the full response from the server
+
+**Powering a Page**: This feature allows you to integrate a specification into a Hub's Page or Subpage. Ideal for integrating information from an external data source to drive the content shown on a Hub page 
+
+**Path Parameter**: A path parameter is the variable part of a URL path and it is often used to point to a specific resource within a collection. A URL can have one or more path parameters with each parameter represented by a pair of curly braces {}
+
+**Query Parameter**: These are parameters in the query string that appear at the end of the request URL. Query parameters are key-value pairs that follow a question mark (?), and are separated by an ampersand (&)
+
+**Models**: Models describe common structures in your API design. Models help reduce duplication in your API definitions and increases future maintainability 
+
+**Shared Models**: Models that can be used in several APIs across your projects 
+
+**Config**: Contains configuration details about the API and lists the version number 
+
+### File Types 
+
+**YAML**: YAML is a human friendly, Unicode-based data serialization standard for all programming languages. Also referred to as 'YAML Ain't Markup Language' or 'Yet Another Markup Language' 
+
+**.oas2**: File extension indicating the file is an OpenAPI v2(fka Swagger) file. You can create an OpenAPI v2 file with the Design Editor in Stoplight 
+
+**.hub**: File extension indicating file is a technical documentation file. Stoplight's Hubs creates .hub files
+
+**.prism**: File extension indicating file is a Prism file 
+
+**.md**: File extension indicating file is a markdown file 
+
+## Hubs 
+
+**Sidebar Token**: This is an extra, compact CSS customization for Hubs. Ideal for adding a short token for use in the sidebar of a Hub
+
+**Page**: Basic elements of a Hub. They function as the starting point for any Hub and each page is automatically added as a link in the Hub's header
+
+**Subpage**: Nested pages within a page. You can have subpages nested within a subpage 
+
+**Blocks**: Editors for creating elements that make up your Hub 
+
+**Markdown**: Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy to read/write text format, then convert it to structurally valid XHTML (or HTML)
+
+## Designing 
+
+**CRUD builder**: Used to create all relevant CRUD operations for a defined model 
+
+**API base path**: The base path on which an API is served relative to the host 
+
+**Version**: Indicates the version of the API (should not be confused with specification)
+
+**Terms of Service URL**: URL to the Terms of Service for an API 
+
+### Global Settings 
+
+**Supported Schemes**: This is the transfer protocol for the API. Supported protocols include HTTP, HTTPS, WS, and WSS
+
+**Request MIME Types**: A list of MIME types the API can consume. This is global to all APIs but can be overridden on specific API calls 
+
+**Response MIME Types**: A list of MIME types that API can produce. This is global to all APIs but can be overriden on specific API calls 
+
+**Global Security**: Security schemes that you can use globally and in operations 
+
+**Contact**: Contact name, email, and URL for owner or managing organization of the specification 
+
+**License**: Includes deatils for license name and URL for the license used by the API
+
+### Security 
+
+**Key**: This is a special key property for the security definition. It must be unique to the specification 
+
+**Type**: Describes the type of security scheme used in the API. Includes: Basic, APIKey, and OAuth2 security schemes 
+
+**In**: Indicates the location of the API key. This could be in the query or header 
+
+**Name**: The name of the header or query parameter to be utilized 
+
+### Paths 
+
+**operationID**: Unique string that identifies an operation. The value of the operationID must be unique among all operations described in the API specification 
+
+**Deprecated**: This property indicates an operation is deprecated 
+
+**Consumes**: Describes the MIME types an operation can consume
+
+**Produces**: Describes the MIME types an operation can produce 
+
+## Scenarios 
+
+**Before Scenario**: Lists the scenarios that are run before the main collection scenarios 
+
+**After Scenario**: Lists the scenarios that are run after the main collection scenarios 
+
+**Utility Scenario**: Used to de-duplicate common tasks. They are not run with the scenarios in your collection and can be referenced from other scenarios 
+
+**Collection**: This is a top-level object that holds many scenarios 
+
+**Trigger This Collection**: This section gives you options for running your collection. You can choose to trigger your collection through Prism or, a specific URL within Stoplight Scenarios 
+
+### Swagger/OAS Coverage 
+
+**Coverage**: The Coverage Report gives you a quick overview of the parts in the connected specs covered by test assertions in the current Scenarios Collection
+
+**Contract Test Settings**: Indicates the API involved in the contract testing process
+
+**2xx Code Asserted**: Defines the list of expected 2xx status codes 
+
+**All Codes**: Defines the list of expected status codes 
+
+### Run Result 
+
+**Assertions**: This property indicates the number of assertions within a Collection 
+
+**Passed**: This property indicates the number of succesful assertions within an executed Collection 
+
+**Failed**: This property indicates the number of failed assertions within an exectued Collection
+
+**Time Taken**: This property indicates the amount of time taken to execute a Collection 
+
+**Slowest Scenario**: A scenario with the highest execution time 
+
+**Output**: Full object that is returned after running a Scenario
+
+### Scenario Config 
+
+**ID**: Unique ID for identifying a scenario 
+
+**Stage**: Describes the level the scenario resides in. It includes Before, Scenarios, After, and Utilites 
+
+**$$.env**: This object gives you access to environment variables 
+
+### Steps 
+
+**HTTP/Script/Reference**: Outlines different step types available in a Scenario. A step can be one of three types: HTTP, Script, or Reference 
+
+**$.ctx**: This variable is used for passing data in between steps 
+
+**Scripts**: Scripts are used to enhance your conditional logic or processing and gives you access to the $.ctx variable 
+
+**Original Request**: Shows the HTTP Request as it was sent, after all transformations, scripts, and variable replacements were run 
+
+**Utilites**: Utility scenarios are used to de-duplicate common tasks and you can reference them from other scenarios 
+
+## Prism 
+
+**Prism**: Prism is a performant, dependency-free server, designed specifically to work with web APIs 
+
+**Mock Server**: Prism understands OpenAPI and can act as a mock server, routing incoming requests to example responses, or dynamically generating examples on the fly 
+
+**Prism Instance**: A Prism Instance is a specific implementation of the Prism server. It can be executed locally or from a hosted location 
+
+**APIS**: List of APIs used to match incoming requests, which can then be forwarded to upstream servers 
+
+**Upstream URL**: Indicates the URL that will receive forwarded requests 
+
+**Methods**: Used to indicate the methods that will be matched in forwarded requests 
+
+**Hosts**: IP address (IPv4) or domain name that serves the API 
+
+**Paths**: Includes related endpoints exposed by an API
+
+**Connected Specs**: This feature is used for linking related specification files. You can connect to specification files internally or externally 
+
+### Matched Rules 
+
+**Before**: Before Rules are executed on incoming traffic before it gets to the end API server 
+
+**After**: After Rules are executed on traffic coming back from the end API 
+
+**Done**: Rules in the phase are executed after the rules for the incoming and outgoing traffic 
+
+## JSON/OpenAPI Terms 
+
+**Swagger**: A specification for documenting and defining REST APIs (See OAS Specification) 
+
+**OAS**: Acronym for OpenAPI Specification (fka Swagger), a specification for documenting and defining REST APIs
+
+**OpenAPI**: Synonym of OAS
+
+**OAS Specification**: Machine-readable interface files for describing, designing, consuming, and visualizing RESTful APIs 
+
+**REST**: Acronym for Representational State Transfer, an architectural style for developing web services 
+
+**SOAP**: Acronym for Simple Object Access Protocol, a lightweight protocol for exchanging information in a decentralized, distributed environment 
+
+**GraphQL**: A data query language for APIs 
+
+**JSON**: Acronym for JavaScript Object Notation, a simple data interchange format 
+
+**Responses**: A server's reply to a request. Usually conists of a status code, reason phrase, and other elements 
+
+**Schema**: A declarative format that describes the structure of other data 
+
+**Required**: A value or a definition that is an absolute requirement and must be provided
+
+**Endpoints**: An endpoint is an entity or resource that can be referenced and is usually represented as the URL of a server or service
+
+### Requests 
+
+**GET**: HTTP method used for requesting or retrieving data from a specific resource 
+
+**PUT**: HTTP method for overwriting a representation of a specific resource or creating a new resource if it does not exist 
+
+**POST**: HTTP method used to create a new resource 
+
+**PATCH**: HTTP method for making partial updates to a resource 
+
+**DELETE**: HTTP method for deleting a specific resource 
+
+## Formats 
+
+**Int32**: A 32-bit signed integer 
+
+**Int64**: A 64-bit signed integer 
+
+**Float**: Single-precision 32-bit floating point number 
+
+**Double**: Double-precision 64-bit floating point number 
+
+**Byte**: Base64-encoded string of bytes 
+
+**Binary**: Sequence of octets or bytes storing raw-byte data 
+
+**Date**: RFC3339 date format given as YYYY-MM-DD 
+
+**Date-time**: RFC3339 timestamp in UTC time gives as YYYY-MM-DDThh:mm:ss.fffZ. The milliseconds segment (.fff) is optional 
+
+**Password**: String data type with masked format for UI to hide an input
+
+**Email**: String data type with email format
+
+
+

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/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)

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 ', '