Compare commits

...

9 Commits

Author SHA1 Message Date
Robert Wallach
e77a4cc420 Update reference-spec.md 2018-03-16 12:22:19 -05:00
Robert Wallach
901da1746a Update reference-spec.md 2018-03-14 13:19:03 -05:00
Nicholas Cassera
3baf13bdd4 version 2 2018-03-01 16:00:51 -06:00
Nicholas Cassera
045f87466d referencing another specification article 2018-03-01 15:04:52 -06:00
Nicholas Cassera
4f1c9fdeee develop -> branch 2018-03-01 14:48:55 -06:00
Robert Wallach
553f891665 Update contract-testing.md 2018-02-20 12:56:35 -06:00
Robert Wallach
96393e0548 Update contract-testing.md 2018-02-20 12:54:00 -06:00
Ross McDonald
bbe034155b Remove polymorphic objects article, since its pretty much the same things as object-inheritance. (#144) 2018-02-20 10:33:16 -06:00
Nicholas Cassera
68e7016ce2 reference-spec initial 2018-02-05 17:19:44 -06:00
2 changed files with 42 additions and 44 deletions

View File

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

View File

@@ -1 +1,43 @@
# Referencing Another API Specification
<!-- REFBUILDER GIF/VIDEO-->
## What
Referencing another specification allows for cleaner and more organized code. Some use cases are as follows:
* Generate API documentaion in Hubs
* Deduplicate common structures like responses or shared parameters in Modeling
* Test a connected API specification in Scenarios
* Setup a mock server for an API in Prism
## How
1. Choose the **source**
* This File
* This Project
* Select a **file**
* Shared/Common
* External URL
* Enter a valid **URL** to an existing specification
2. Select a **target**, if required
3. Confirm your choice. (Only required if there is a confirm button)
4. View the referenced specification by clicking the book icon
---
**Related Links**
* [Reference other Sources](../hubs/ref-other-sources-hubs.md)
* [Creating Models](../modeling/how-to-create-models.md#How-to-Create-Models-using-the-Stoplight-Modeling-Editor)
* [Shared Parameters and Responses](../modeling/shared-params-responses.md)
* [Contract Testing](../testing/contract-testing.md#connecting-the-spec)
* [Setting Up a Prism Mock Server](../prism/mocking.md)