Merge branch 'develop' into jason/review

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

articles/modeling/polymorphic-objects.md

@@ -1,44 +1,42 @@
-# Polymorphic Objects 
+# Polymorphic Objects
 
-## What 
+## 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. 
+* 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. 
+## 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 
+> 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.
 
-```
-{
-  definitions:
+### Example
+
+```yaml
+definitions:
   Vehicle:
-    type: object, 
-    discriminator: brand
+    type: object,
+    discriminator: model
     properties:
       model:
         type: string
       color:
         type: string
-      required:
-    model
-    
-  Sedan: # Sedan is used as the discriminator value 
-  
+    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
-}
+      - $ref: '#/definitions/Vehicle'
+      - type: object
+          properties:
+            dateManufactured:
+              type: date
+          required:
+            - dateManufactured
 ```

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.