Compare commits
118 Commits
rowa97-pat
...
articles/t
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
5972806727 | ||
|
|
c805cd366b | ||
|
|
390665c014 | ||
|
|
830720e369 | ||
|
|
3225b306df | ||
|
|
e1a6a78e2e | ||
|
|
fe75517632 | ||
|
|
489ba847b4 | ||
|
|
b96e858b42 | ||
|
|
a7e86b8d2b | ||
|
|
d0d4119a57 | ||
|
|
17a885d446 | ||
|
|
8dcc2827aa | ||
|
|
c221dcbe72 | ||
|
|
889fde6361 | ||
|
|
149656016a | ||
|
|
7a8df8e995 | ||
|
|
6b8956a0b1 | ||
|
|
b9db9ff09c | ||
|
|
a317bd989b | ||
|
|
d92282e250 | ||
|
|
921eaf91ed | ||
|
|
132a8bf65a | ||
|
|
662f0a83fd | ||
|
|
ea25661c7b | ||
|
|
e1d2e27dde | ||
|
|
9d6e314c69 | ||
|
|
bbf1b80dd7 | ||
|
|
75990e4d4b | ||
|
|
451ec6ea92 | ||
|
|
90e59b3d3b | ||
|
|
2dd66db90a | ||
|
|
fc797fe315 | ||
|
|
71ed05aff6 | ||
|
|
9d1c62719b | ||
|
|
c8821ebbfc | ||
|
|
065b228906 | ||
|
|
c7908c1869 | ||
|
|
a81330b857 | ||
|
|
553838c469 | ||
|
|
a46de58839 | ||
|
|
c2530594a3 | ||
|
|
d64c1db923 | ||
|
|
a70c538118 | ||
|
|
b0a6144e0f | ||
|
|
9489ab6235 | ||
|
|
946e0b3392 | ||
|
|
4405807bfc | ||
|
|
1529b1e06f | ||
|
|
be9f29bb7c | ||
|
|
4ea895d42f | ||
|
|
d29ba322b8 | ||
|
|
0a7d57fe02 | ||
|
|
7fbb9211fe | ||
|
|
27bb1b6d6b | ||
|
|
24b0940924 | ||
|
|
94db6d3088 | ||
|
|
94e2154fe1 | ||
|
|
8555af7195 | ||
|
|
b9079c527b | ||
|
|
c326f6771d | ||
|
|
f73a319d99 | ||
|
|
ca87888811 | ||
|
|
45af6bf2fd | ||
|
|
03da7bcac9 | ||
|
|
8209778a55 | ||
|
|
1809bd9397 | ||
|
|
9e0cf97dfd | ||
|
|
a45948bb33 | ||
|
|
11468e8f89 | ||
|
|
3a5beb4a8c | ||
|
|
d3a35dfef8 | ||
|
|
442030b842 | ||
|
|
7d58a3dd45 | ||
|
|
975838c495 | ||
|
|
533e08502d | ||
|
|
e44c5fc6aa | ||
|
|
b60edc26c7 | ||
|
|
4c10587e03 | ||
|
|
7f7c6ef4f7 | ||
|
|
5947b9c764 | ||
|
|
a7383121a8 | ||
|
|
eed2b4ab55 | ||
|
|
a74acff595 | ||
|
|
a0ba071b1a | ||
|
|
be7e72b355 | ||
|
|
facff9dbba | ||
|
|
73c4a8fd86 | ||
|
|
1417ad2278 | ||
|
|
1871b9744d | ||
|
|
81b359ed20 | ||
|
|
ec7403fccc | ||
|
|
dcb7c8391c | ||
|
|
8033d3ce19 | ||
|
|
619d23dab1 | ||
|
|
f793b695d6 | ||
|
|
26554c026d | ||
|
|
0512c0386e | ||
|
|
8770c8a461 | ||
|
|
e6e993c1f6 | ||
|
|
fb54460cba | ||
|
|
fb465246cd | ||
|
|
823f0cfa48 | ||
|
|
1c17bf6e19 | ||
|
|
aaf2cfe2fe | ||
|
|
1f99714844 | ||
|
|
a708f52d3c | ||
|
|
479fa10722 | ||
|
|
7a49103b10 | ||
|
|
f97148dcc9 | ||
|
|
f98b70942a | ||
|
|
0ab7dbbe1c | ||
|
|
86ffe00f1e | ||
|
|
88a7f677f2 | ||
|
|
dc1d63fe5d | ||
|
|
c0b0c1045c | ||
|
|
a57f88662c | ||
|
|
5e9b978b9e |
@@ -3,11 +3,19 @@
|
||||

|
||||
|
||||
## What
|
||||
Changing your email address is easy as pie
|
||||
Changing your email address is easy as pie.
|
||||
|
||||
## How
|
||||
1. Click on your **username** in the top right
|
||||
2. Click on the **Account** button.
|
||||
2. Click on the **Account** button
|
||||
3. In the **Basic Info** section, replace the email listed with one you would like to change to
|
||||
4. Click **Save** and you’re all done
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Sign In to Stoplight](/platform/getting-started/account-basics/sign-in)
|
||||
- [Edit Your Profile](/platform/getting-started/account-basics/edit-profile)
|
||||
- [Manage Your Password](/platform/getting-started/account-basics/manage-password)
|
||||
- [Change Your Username](/platform/getting-started/account-basics/change-username)
|
||||
- [Sign Out of Stoplight](/platform/getting-started/account-basics/sign-out)
|
||||
- [Deactivate Your Stoplight Account](/platform/getting-started/account-basics/deactivate)
|
||||
|
||||
@@ -8,5 +8,14 @@ You can change your username at any time
|
||||
## How
|
||||
1. Click on your current **username** in the top right
|
||||
2. Click on **Account**
|
||||
3. Under **Basic Info** input a new username
|
||||
3. Under **Basic Info**, input a new username
|
||||
4. Click **Save**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Sign In to Stoplight](/platform/getting-started/account-basics/sign-in)
|
||||
- [Edit Your Profile](/platform/getting-started/account-basics/edit-profile)
|
||||
- [Manage Your Password](/platform/getting-started/account-basics/manage-password)
|
||||
- [Change Your Email Address](/platform/getting-started/account-basics/change-email)
|
||||
- [Sign Out of Stoplight](/platform/getting-started/account-basics/sign-out)
|
||||
- [Deactivate Your Stoplight Account](/platform/getting-started/account-basics/deactivate)
|
||||
|
||||
@@ -3,20 +3,27 @@
|
||||

|
||||
|
||||
## What
|
||||
* In your profile you can edit things like:
|
||||
* Basic Info
|
||||
* Username
|
||||
* Name
|
||||
* Email
|
||||
* Upload a profile image
|
||||
* Change Password
|
||||
In your profile you can edit things like:
|
||||
* Basic Info
|
||||
* Username
|
||||
* Name
|
||||
* Email
|
||||
* Upload a profile image
|
||||
* Change Password
|
||||
|
||||
## How
|
||||
1. Select your **Username** in the top right corner
|
||||
2. Click **Account**
|
||||
3. Make your edits in **Basic Info** then click **Save**
|
||||
3. Make your edits in **Basic Info**, then click **Save**
|
||||
* You can also click **Reset** if you would like to start from scratch
|
||||
4. Upload a profile image
|
||||
5. Make your edits in Change Password then click **Change Password**
|
||||
* Password must be at least 6 characters
|
||||
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Sign In to Stoplight](/platform/getting-started/account-basics/sign-in)
|
||||
- [Manage Your Password](/platform/getting-started/account-basics/manage-password)
|
||||
- [Change Your Username](/platform/getting-started/account-basics/change-username)
|
||||
- [Change Your Email Address](/platform/getting-started/account-basics/change-email)
|
||||
- [Sign Out of Stoplight](/platform/getting-started/account-basics/sign-out)
|
||||
|
||||
@@ -3,12 +3,20 @@
|
||||

|
||||
|
||||
## What
|
||||
* If you’ve forgotten the password you use to sign in to Stoplight; you can easily reset it at any time
|
||||
If you’ve forgotten the password you use to sign in to Stoplight; you can easily reset it at any time
|
||||
|
||||
## What
|
||||
1. At the login page select **Forgot Password?**
|
||||
1. At the login page, select **Forgot Password?**
|
||||
2. Input your email in the space provided
|
||||
3. Click **Send Email Link**
|
||||
4. An email will be sent with a link to your email address
|
||||
5. Click on the link and you will be sent to an email reset page
|
||||
6. Choose a new password and Voila
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Sign In to Stoplight](/platform/getting-started/account-basics/sign-in)
|
||||
- [Edit Your Profile](/platform/getting-started/account-basics/edit-profile)
|
||||
- [Change Your Username](/platform/getting-started/account-basics/change-username)
|
||||
- [Change Your Email Address](/platform/getting-started/account-basics/change-email)
|
||||
- [Sign Out of Stoplight](/platform/getting-started/account-basics/sign-out)
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Sign In To Stoplight
|
||||
|
||||
## What
|
||||
* There are two separate options for creating your snazzy new Stoplight account:
|
||||
* Login with GitHub
|
||||
* Create a new account
|
||||
There are two separate options for creating your snazzy new Stoplight account:
|
||||
* Login with GitHub
|
||||
* Create a new account
|
||||
|
||||
## How
|
||||
|
||||
@@ -23,3 +23,10 @@
|
||||
* Password must be more than 6 characters
|
||||
6. Click **Join Stoplight**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Edit Your Profile](/platform/getting-started/account-basics/edit-profile)
|
||||
- [Manage Your Password](/platform/getting-started/account-basics/manage-password)
|
||||
- [Change Your Username](/platform/getting-started/account-basics/change-username)
|
||||
- [Change Your Email Address](/platform/getting-started/account-basics/change-email)
|
||||
- [Sign Out of Stoplight](/platform/getting-started/account-basics/sign-out)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Sign Out of Stoplight
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* By default, Stoplight remains open. If you wish to sign out follow these quick and easy steps
|
||||
@@ -9,3 +9,12 @@
|
||||
1. Click on your **username** in the top right corner
|
||||
2. In the dropdown menu select **Sign Out**
|
||||
3. All set, come back soon!
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Sign In to Stoplight](/platform/getting-started/account-basics/sign-in)
|
||||
- [Edit Your Profile](/platform/getting-started/account-basics/edit-profile)
|
||||
- [Manage Your Password](/platform/getting-started/account-basics/manage-password)
|
||||
- [Change Your Username](/platform/getting-started/account-basics/change-username)
|
||||
- [Change Your Email Address](/platform/getting-started/account-basics/change-email)
|
||||
|
||||
|
||||
@@ -21,3 +21,7 @@ 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
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Mocking Introduction](/mocking/introduction)
|
||||
|
||||
@@ -1 +1,32 @@
|
||||
# Viewing Changes
|
||||
|
||||
As more users edit files within the same project, tracking changes over time
|
||||
becomes increasingly difficult. To mitigate these effects, Stoplight provides the full history of changes, which allows you to view and track any changes made.
|
||||
|
||||
To see the history of changes for a project, use the 'History' button on the
|
||||
navigation bar to the left of the project window (shown below). When the history
|
||||
is being viewed, you will see a series of changes for the project, listed in
|
||||
descending order by date.
|
||||
|
||||

|
||||
|
||||
Each change event includes:
|
||||
|
||||
* The date when the change was made
|
||||
|
||||
* The user who made the change
|
||||
|
||||
* The files updated by the change
|
||||
|
||||
* The differences (known as the 'diff') between each file before and after the
|
||||
change occurred
|
||||
|
||||
See the image below for an overview of the contents of the change view.
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Working with Files](./working-with-files.md)
|
||||
|
||||
@@ -1,24 +1,23 @@
|
||||
# Welcome to Stoplight NEXT!
|
||||
# Welcome to Stoplight Next!
|
||||
|
||||

|
||||

|
||||
|
||||
Now that you have the basics on what the [Stoplight NEXT Platform](../what-is-stoplight.md) is, we can go over how to get started.
|
||||
Now that you have the basics on what the [Stoplight Next Platform](/platform/introduction) is, we can go over how to get started.
|
||||
|
||||
First things first, are you using it for Personal Projects or as part of an Organization?
|
||||
First things first, are you using Stoplight for Personal Projects or as part of an Organization?
|
||||
|
||||
## Personal Projects
|
||||
1. Create an Account (link)
|
||||
2. Create a Project (link)
|
||||
1. [Sign In](/platform/getting-started/account-basics/sign-in)
|
||||
2. [Create a Project](/platform/projects/creating-a-project)
|
||||
|
||||
## Organization
|
||||
1. Create an Account (link)
|
||||
2. Create an Organization (link)
|
||||
3. Invite Members (link)
|
||||
4. Accept an Organization Invite
|
||||
5. Create a Project (link)
|
||||
1. [Sign In](/platform/getting-started/account-basics/sign-in)
|
||||
2. [Create an Organization](/platform/organizations/create-org)
|
||||
3. [Invite Members](/platform/organizations/invite-people)
|
||||
4. [Create a Project](/platform/projects/creating-a-project)
|
||||
|
||||
## Web App or Download
|
||||
* You can log in to the Web App at [next.stoplight.io](http://next.stoplight.io) or
|
||||
* You can download the platform here (link)
|
||||
* You can download the platform [here](https://github.com/stoplightio/desktop/releases/latest)
|
||||
|
||||
If you have any questions you can reach out to us through Intercom or email us at [support@stoplight.io](support@stoplight.io) otherwise... **Full Steam Ahead!**
|
||||
|
||||
@@ -9,29 +9,29 @@ If you are trying to create a new Organization then you are in the right place.
|
||||
## Organization
|
||||
Organizations function as a shared space for you and your co-workers. Members of an Organization have access to a centralized Activity Feed, Project Repository, and an Issues (link) discussion tool. Organization Owners can also assign varying levels of Permissions to other members of the Organization.
|
||||
|
||||
* Create an Organization (link)
|
||||
* Invite People to Organization (link)
|
||||
* Remove People from your Organization (link)
|
||||
* Member Roles and Permissions (link)
|
||||
* Customize your Organization (link)
|
||||
* Transfer Primary Ownership (link)
|
||||
* Delete an Organization (link)
|
||||
* [Create an Organization](./create-org.md)
|
||||
* [Invite People to Organization](./managing-people.md)
|
||||
* [Remove People from your Organization](./remove-people.md)
|
||||
* [Member Roles and Permissions](./roles.md)
|
||||
* [Customize your Organization](./customize-org.md)
|
||||
* [Transfer Primary Ownership](./transferring-ownership.md)
|
||||
* [Delete an Organization](./delete-org.md)
|
||||
|
||||
## Teams
|
||||
If you are managing a large Organization with multiple teams you can use Teams to group Organization members together.
|
||||
|
||||
* Create a Team (link)
|
||||
* Add People to a Team (link)
|
||||
* Remove People from a Team (link)
|
||||
* Member Roles and Permissions (link)
|
||||
* Customize a Team (link)
|
||||
* Transfer Primary Ownership (link)
|
||||
* Delete a Team (link)
|
||||
* [Create a Team](./create-team.md)
|
||||
* [Add People to a Team](./add-people.md)
|
||||
* [Remove People from a Team](./remove-people.md)
|
||||
* [Member Roles and Permissions](./member-roles.md)
|
||||
* [Customize a Team](./customize-team.md)
|
||||
* [Transfer Primary Ownership](./transfer-ownership.md)
|
||||
* [Delete a Team](./delete-team.md)
|
||||
|
||||
## Projects
|
||||
Projects are the workspaces you can create for your Organization.
|
||||
|
||||
* Creating a Project (link)
|
||||
* Invite People & Teams to a Project (link)
|
||||
* Change a Project Member’s Role (link)
|
||||
* Make Your Project Private/Public (link)
|
||||
* [Creating a Project](./create-project.md)
|
||||
* [Invite People & Teams to a Project](./invite-people-team.md)
|
||||
* [Change a Project Member’s Role](./change-member-role.md)
|
||||
* [Make Your Project Private/Public](./visibility.md)
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# The Stoplight Platform
|
||||
The Stoplight platform provides a suite of products that cover the entire pre-production API lifecycle. Here is an overview of the platform:
|
||||
|
||||

|
||||

|
||||
|
||||
Stoplight promotes a design-first philosophy. Developing good design-first practices at your organization will minimize future cost, speed up your time to market, and lead to more consistent, higher quality APIs.
|
||||
|
||||
@@ -17,7 +17,7 @@ Once you have your API design / documentation, how do you make sure that it rema
|
||||
|
||||

|
||||
|
||||
## Hosted Documentation
|
||||
## Documentation
|
||||
|
||||
You have your API designed and documented privately in the Stoplight app, and now you want to share all or part of it with 3rd parties (developers, customers, clients, etc). Stoplight makes it easy to publish your documentation to the world, with a single click.
|
||||
|
||||
@@ -27,10 +27,3 @@ You have your API designed and documented privately in the Stoplight app, and no
|
||||
## Mock Server
|
||||
Stoplight provides a complete mock server for every API described in the app. Run tests against this mock server, build consumers (like mobile apps, SDKS, etc) before the final API is ready, and more.
|
||||
|
||||
Spinning up your own mock server is as simple as:
|
||||
|
||||
# install prism on macOS
|
||||
curl https://raw.githubusercontent.com/stoplightio/prism/master/install.sh | sh
|
||||
|
||||
# run a fake petstore api on http://localhost:4010
|
||||
prism run --mock --list --spec http://petstore.swagger.io/v2/swagger.json
|
||||
|
||||
@@ -5,7 +5,8 @@
|
||||
## What
|
||||
Blocks are the micro-level building blocks of Hubs. They house multiple forms of content and allow for simple restructuring and modification.
|
||||
|
||||
<callout> Hovering over a Block reveals additional tooling including: Preview, Cut, Copy, Reference External Source, and Delete </>
|
||||
<!-- theme: info -->
|
||||
>Hovering over a Block reveals additional tooling including: Preview, Cut, Copy, Reference External Source, and Delete
|
||||
|
||||
## Block Types
|
||||
### Text Block
|
||||
@@ -31,3 +32,8 @@ Blocks are the micro-level building blocks of Hubs. They house multiple forms of
|
||||
### HTML
|
||||
* Include arbitrary HTML in your hubs when the other base block types don't quite do the trick
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Pages](./pages.md)
|
||||
- [Subpages](./subpages.md)
|
||||
- [Reference Other Sources](./ref-other-sources-hubs.md)
|
||||
|
||||
@@ -24,7 +24,13 @@ Pages are the macro level building blocks of a Hub. They function as the canvas
|
||||
2. Input a **Page Route** (optional)
|
||||
3. **Power the Page** with an External Data Source (optional)
|
||||
|
||||
<callout> Did you know? After creating a new page; a header link will automatically be generated </>
|
||||
<!-- theme: info -->
|
||||
>Did you know? After creating a new page; a header link will automatically be generated
|
||||
|
||||
---
|
||||
**Related Articlers**
|
||||
- [Subpages](./subpages.md)
|
||||
- [Blocks](./blocks.md)
|
||||
- [Routing](./routing.md)
|
||||
|
||||
<callout> To add content to a page you must add a subpage or a content block </>
|
||||
|
||||
|
||||
@@ -1 +1,33 @@
|
||||
# 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.
|
||||
|
||||
<!-- theme: info -->
|
||||
>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**
|
||||
|
||||
@@ -7,31 +7,37 @@
|
||||
Stoplight’s Hubs features an easy to use routing system to make sure your docs have identifiable and friendly URL’s. The routing system allows customization of the following objects:
|
||||
|
||||
- Your Hub
|
||||
- Pages within a Hub (link)
|
||||
- Subpages within a Hub (link)
|
||||
- Headers + Footers (link)
|
||||
- [Pages within a Hub](./pages.md)
|
||||
- [Subpages within a Hub](./subpages.md)
|
||||
- [Headers + Footers](./managing-headers-footers.md)
|
||||
- Links
|
||||
|
||||
<callout>Tips for Friendly URL’s
|
||||
|
||||
Friendly URLs are links that are easily readable, rememberable, and relevant to the content.
|
||||
Take a look at the URL for this page. Instead of something like https://help.stoplight.io/docs/fnIenof/123, it is https://help.stoplight.io/docs/hosted-documentation/create-friendly-urls, which is much nicer. </>
|
||||
<!-- theme: info -->
|
||||
>Friendly URLs are links that are easily readable, rememberable, and relevant to the content.
|
||||
|
||||
|
||||
## How
|
||||
|
||||
### Pages & Subpages
|
||||
|
||||
1. Select the Hub you wish to modify
|
||||
2. Add a new page or subpage (link)
|
||||
a. Select a page title to auto-fill the Page Route or
|
||||
b. Input a custom page route
|
||||
3. Select an existing page or subpage
|
||||
4. Select the gear icon at the top of the Hub in the center of the page or subpage you wish to modify
|
||||
a. Input a new URL under Page Route
|
||||
1. Select the **Hub** you wish to modify
|
||||
2. Add a new **page** or **subpage** (link)
|
||||
1. Select a **page title** to auto-fill the **Page Route** or
|
||||
2. Input a **custom page route**
|
||||
3. Select an **existing page** or **subpage**
|
||||
4. Select the **gear icon** at the top of the Hub in the center of the page or subpage you wish to modify
|
||||
1. Input a **new UR**L under Page Route
|
||||
|
||||
### Headers & Footers
|
||||
|
||||
1. Select the Hub you wish to modify
|
||||
2. Add a new header or footer (link) or
|
||||
3. Hover over an existing header or footer and click the gear icon
|
||||
a. Input a Path to Page or image URL
|
||||
1. Select the **Hub** you wish to modify
|
||||
2. Add a new **header or footer** (link) or
|
||||
3. Hover over an existing header or footer and click the **gear icon**
|
||||
a. Input a **Path to Page** or **image URL**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Pages within a Hub](./pages.md)
|
||||
- [Subpages within a Hub](./subpages.md)
|
||||
- [Headers + Footers](./managing-headers-footers.md)
|
||||
|
||||
@@ -5,6 +5,9 @@
|
||||
## What
|
||||
Subpages are the second tier macro building blocks of Hubs. They function as a canvas for blocks. They are commonly used to house content based on a specific topic. Subpages can have more subpages nested underneath them, which gives you lots of flexibility to organize your Hub as you see fit. If a subpage has subpages nested inside of it, it will be displayed as a collapsible group in the left sidebar.
|
||||
|
||||
<!-- theme: info -->
|
||||
>Subpages populate the navigational sidebar of a page.
|
||||
|
||||
### Hubs Architecture Top Down
|
||||
- Pages
|
||||
- Subpages
|
||||
@@ -24,7 +27,12 @@ Subpages are the second tier macro building blocks of Hubs. They function as a c
|
||||
3. Give the Subpage a **Sidebar Token** (optional)
|
||||
4. **Power the Subpage** with an External Data Source (optional)
|
||||
|
||||
<callout> Subpages populate the navigational sidebar of a page. </>
|
||||
|
||||
<callout> Just like pages, subpages can have blocks. Any blocks added to a subpage will be displayed when a reader navigates to that subpage in your hub</>
|
||||
<!-- theme: info -->
|
||||
>Just like pages, subpages can have blocks. Any blocks added to a subpage will be displayed when a reader navigates to that subpage in your Hub
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Pages](./pages.md)
|
||||
- [Headers & Footers](./managing-headers-footers.md)
|
||||
- [Routing](./routing.md)
|
||||
- [Publishing](./publishing.md)
|
||||
|
||||
@@ -1,37 +1,87 @@
|
||||
# API Models
|
||||
An API model is a blueprint that identifies the requirements and proposed solution for an API development project. A well crafted API model indicates you understand the problem you are trying to solve. The following steps can help you get started with creating an excellent API model.
|
||||
|
||||
## Identify Needs
|
||||
During interactive sessions with stakeholders, outline all the requirements you want your API to meet . Some important questions to ask:
|
||||
- What goal(s) do we want to achieve with the API?
|
||||
- Who are the principal users that will consume or interact with the API?
|
||||
- What activities will the users execute?
|
||||
- How can we group the activities into steps?
|
||||
- What are the API methods that are required for these steps? (Place the methods into common resource groups.)
|
||||
- What resources will the API expose?
|
||||
- What permissions will we need?
|
||||
This process may need to be repeated until the API development team is sure that all requirements are covered.
|
||||
Models are used to describe common structures in your API design. Use models to
|
||||
describe common structures in your API design. Models help reduce duplication in
|
||||
your API definitions, and increase future maintainability.
|
||||
|
||||
## Build a Common Vocabulary
|
||||
Vocabulary is used in your API artifacts such as your data fields, resource names, identifiers, and documentation. Creating a standard vocabulary helps you:
|
||||
- Communicate well with different audiences.
|
||||
- Establish a standard or style guide that can be adopted by members of the API development team.
|
||||
- Easily update your documentation.
|
||||
While designing your APIs, you will often find yourself repeating structures in
|
||||
your endpoint request and response bodies. Models allow you to describe these
|
||||
common structures, and then reference the object from endpoint definitions and
|
||||
other models (with references).
|
||||
|
||||
## Identify Resource Relationships
|
||||
If your resources contain references to other resources or contain child resources, it is important to understand and define the types of relationships between resources because this will help you to show the link between the resources to the API user making the API more readable. Relationships can be:
|
||||
- **Dependent**: the resource cannot exist without a parent resource.
|
||||
- **Independent**: the resource can stand on its own and can reference another resource but does not need another resource to exist or function.
|
||||
- **Associative**: the resources are independent but the relationship includes or needs further properties to describe it.
|
||||
## Effective API Model Design
|
||||
|
||||
## Create a Test Plan
|
||||
Ensuring that your API meets predefined criteria requires testing. Design test plans early. Feasible tests you can execute include:
|
||||
- **Functional Testing**: Test the API calls to ensure that it delivers or behaves as expected. For example, you can test to see that the API delivers the expected data based on your model.
|
||||
- **Mocking** (service simulation): Mocking allows you to execute tests on an API deployment without calling it through a defined API key. Effective API tools will allow you to test your API before implementation.
|
||||
- **Load Testing**: How will your API perform when deployed on a production server? A load test is one way to simulate the effect of traffic on your servers and observe the performance of your API when it is available to users. Doing a load test will help you understand your API threshold and if the users exceed the threshold.
|
||||
An API model can be viewed as a blueprint that identifies the requirements for
|
||||
an API development project. A well crafted API model indicates you understand
|
||||
the problem you are trying to solve.
|
||||
|
||||
## Additional Notes
|
||||
- Create tests that match your use case.
|
||||
- Discuss security issues during your modelling meetings with your team.
|
||||
- Ensure the test case is executed to see if the security issues are addressed before deployment. Click here to know more about security schemes and how to secure your API using best practices.
|
||||
The following steps can help you get started with creating an excellent API
|
||||
model.
|
||||
|
||||
### Identify Needs
|
||||
|
||||
During interactive sessions with stakeholders, outline all the requirements you
|
||||
want your API to meet. Some important questions to ask:
|
||||
|
||||
* What goal(s) do we want to achieve with the API?
|
||||
* Who are the principal users that will consume or interact with the API?
|
||||
* What activities will the users execute?
|
||||
* How can we group the activities into steps?
|
||||
* What are the API methods that are required for these steps? (Place the methods into common resource groups.)
|
||||
* What resources will the API expose?
|
||||
* What permissions will we need?
|
||||
|
||||
This process may need to be repeated until the API development team is sure that
|
||||
all requirements are covered.
|
||||
|
||||
### Build a Common Vocabulary
|
||||
|
||||
Vocabulary is used in your API artifacts such as your data fields, resource
|
||||
names, identifiers, and documentation. Creating a standard vocabulary helps you:
|
||||
|
||||
* Communicate well with different audiences
|
||||
* Establish a standard or style guide that can be adopted by members of the API development team
|
||||
* Easily update your documentation
|
||||
|
||||
### Identify Resource Relationships
|
||||
|
||||
If your resources contain references to other resources or contain child
|
||||
resources, it is important to understand and define the types of relationships
|
||||
between resources because this will help you to show the link between the
|
||||
resources to the API user making the API more readable. Relationships can be:
|
||||
|
||||
* **Dependent**: the resource cannot exist without a parent resource
|
||||
* **Independent**: the resource can stand on its own and can reference another
|
||||
resource but does not need another resource to exist or function
|
||||
* **Associative**: the resources are independent but the relationship includes
|
||||
or needs further properties to describe it
|
||||
|
||||
### Create a Test Plan
|
||||
|
||||
Ensuring that your API meets the agreed-upon specification requires testing.
|
||||
Design test plans early.
|
||||
|
||||
Feasible tests you can execute include:
|
||||
|
||||
* **Functional Testing**: Test the API calls to ensure that it delivers or
|
||||
behaves as expected. For example, you can test to see that the API delivers
|
||||
the expected data based on your model
|
||||
|
||||
* **Mocking** (service simulation): Mocking allows you to execute tests on an
|
||||
API deployment without calling it through a defined API key. Effective API
|
||||
tools will allow you to test your API before implementation
|
||||
|
||||
* **Load Testing**: How will your API perform when deployed on a production
|
||||
server? A load test is one way to simulate the effect of traffic on your
|
||||
servers and observe the performance of your API when it is available to users.
|
||||
Doing a load test will help you understand your API threshold and if the users
|
||||
exceed the threshold
|
||||
|
||||
---
|
||||
|
||||
**Related Articles**
|
||||
|
||||
- [Modeling Introduction](/modeling/introduction)
|
||||
- [Object Inheritance](/modeling/json-best-practices/object-inheritance)
|
||||
- [Testing Overview](/testing/introduction)
|
||||
- [Mock Testing with Prism](/mocking/introduction)
|
||||
|
||||
@@ -1,20 +1,29 @@
|
||||
# API Operations
|
||||
## Introduction
|
||||
API operations describe the way you define how an API is exposed to a user. Properly defined operations are fundamental to the API development life cycle and the outcome is a final product that is easy to understand and use. Creating a properly designed RESTful API requires research, analysis, and planning. It is the API developer’s responsibility to ensure that the API design, resources, and connected operations are easy to understand by consumers. The following characteristics are true of well-designed APIs:
|
||||
|
||||
- Comprehensive, yet succinct
|
||||
- Understandable and easy to use
|
||||
- Supports delta (incremental) development
|
||||
- Expedites and simplifies the API documentation process
|
||||
API operations describe the way you define how an API is exposed to a user. Properly defined operations are fundamental to the API development life cycle and the outcome is a final product that is easy to understand and use. Creating a properly designed RESTful API requires research, analysis, and planning. It is the API developer’s responsibility to ensure that the API design, resources, and connected operations are easy to understand by consumers.
|
||||
|
||||
The following characteristics are true of well-designed APIs:
|
||||
|
||||
* Comprehensive, yet succinct
|
||||
* Understandable and easy to use
|
||||
* Supports delta (incremental) development
|
||||
* Expedites and simplifies the API documentation process
|
||||
|
||||
## Key Terms
|
||||
- A **resource** is an entity or object that has data linked to it, relationships to other objects or entities, and a set of methods that operate on it to access, use, or manipulate the associated data. When resources are grouped together, it is called a collection.
|
||||
- A **Uniform Resource Locator (URL)** is used to indicate and identify the location of an API resource and perform some actions to it. Note that the base URL is the constant part of this location.
|
||||
- **GET** method requests data from a resource and the body of the response message holds the information requested.
|
||||
- **PUT** method requests the server to update the resource or create it (if it does not exist) and the body of the request message indicates the resource to be updated or created.
|
||||
- **PATCH** method performs a partial update on a resource and the body of the request message indicates the change to be applied. This can occasionally be more efficient than PUT because the client forwards changes required and not the entire details about the resource.
|
||||
- **POST** creates a new resource and the body of the request message indicates the details of the new resource to be created. This method can be used to activate operations that will not create a resource.
|
||||
- **DELETE** method requests that the specified resource be removed.
|
||||
|
||||
* A **resource** is an entity or object that has data linked to it, relationships to other objects or entities, and a set of methods that operate on it to access, use, or manipulate the associated data. When resources are grouped together, it is called a collection
|
||||
|
||||
* A **Uniform Resource Locator (URL)** is used to indicate and identify the location of an API resource and perform some actions to it. Note that the base URL is the constant part of this location
|
||||
|
||||
* **GET** method requests data from a resource and the body of the response message holds the information requested
|
||||
|
||||
* **PUT** method requests the server to update the resource or create it (if it does not exist) and the body of the request message indicates the resource to be updated or created
|
||||
|
||||
* **PATCH** method performs a partial update on a resource and the body of the request message indicates the change to be applied. This can occasionally be more efficient than PUT because the client forwards changes required and not the entire details about the resource
|
||||
|
||||
* **POST** creates a new resource and the body of the request message indicates the details of the new resource to be created. This method can be used to activate operations that will not create a resource
|
||||
|
||||
* **DELETE** method requests that the specified resource be removed
|
||||
|
||||
## Best Practices
|
||||
|
||||
@@ -22,69 +31,86 @@ API operations describe the way you define how an API is exposed to a user. Prop
|
||||
|
||||
For example, to retrieve pet details for a pet store which has different kinds of pets:
|
||||
|
||||
- /pets (Good)
|
||||
- /getAllPets (Bad)
|
||||
* `/pets` (Good)
|
||||
* `/getAllPets` (Bad)
|
||||
|
||||
<!-- theme: info -->
|
||||
> A good resource URL contains resources (nouns) and not actions or verbs. Ensure that the resource is in the plural form at the API endpoint.
|
||||
|
||||
### Use HTTP methods to operate on resources
|
||||
|
||||
To add, delete, or update information, use the HTTP methods GET, POST, DELETE, PUT, and PATCH (also known as verbs). For example:
|
||||
|
||||
- GET /pets (returns the list of all pets)
|
||||
- GET /pets/5 (returns details of pet 5)
|
||||
* `GET /pets` (returns the list of all pets)
|
||||
* `GET /pets/5` (returns details of pet 5)
|
||||
|
||||
<!-- theme: info -->
|
||||
> A successful GET method normally returns a HTTP status code of 200 (OK) and 404 (Not found) if the resource cannot be located.
|
||||
|
||||
| GET | PUT/PATCH | POST | DELETE | Resource |
|
||||
|---------------------------------------|-----------------------------------------------|-------------------------------------|---------------------------------------------|------------------------|
|
||||
| Return list of all pets | Update all pets | Add a new pet | Remove all pets | path/pets |
|
||||
| Return details of treatment for pet 5 | Update all treatment for pet 5 | Add new treatment details for pet 5 | Remove all treatments associated with pet 5 | path/pets/5/treatments |
|
||||
| Returns details for pet 5 | Updates details for pet 5 assuming it exists | Error (Not permitted) | Deletes pet 5 details | path/pets/5 |
|
||||
| GET | PUT/PATCH | POST | DELETE | Resource |
|
||||
| ------------------------------------- | -------------------------------------------- | ----------------------------------- | ------------------------------------------- | ---------------------- |
|
||||
| Return list of all pets | Update all pets | Add a new pet | Remove all pets | path/pets |
|
||||
| Return details of treatment for pet 5 | Update all treatment for pet 5 | Add new treatment details for pet 5 | Remove all treatments associated with pet 5 | path/pets/5/treatments |
|
||||
| Returns details for pet 5 | Updates details for pet 5 assuming it exists | Error (Not permitted) | Deletes pet 5 details | path/pets/5 |
|
||||
|
||||
### Make use of a Query String (?) for complex parameter optional parameters
|
||||
|
||||
When you need to add more complexity and dynamics to the request, add parameters to the query string. For example:
|
||||
|
||||
- GET /pets?type=feline&age=5 (Good)
|
||||
- getFelinePets (Bad)
|
||||
* `GET /pets?type=feline&age=5` (Good)
|
||||
* `getFelinePets` (Bad)
|
||||
|
||||
### Utilize HTTP Status Codes
|
||||
|
||||
### Utilize HTTP Status Codes
|
||||
A user should know the status of request made through an API. This might include failed, passed, or invalid responses. The table below summarizes the codes.
|
||||
|
||||
| 2xx Success | 3xx Redirect | 4xx Client Error | 5xx Server Error |
|
||||
|-------------------------------------------------------------------------|-----------------------|------------------|---------------------------|
|
||||
| ----------------------------------------------------------------------- | --------------------- | ---------------- | ------------------------- |
|
||||
| 200 Ok (Success for GET, PUT, or POST) | 301 Moved Permanently | 400 Bad Request | 550 Internal Server Error |
|
||||
| 201 Created | 304 Not Modified | 401 Unauthorized | |
|
||||
| 204 No Content (Request successfully processed but returns not content) | | 403 Forbidden | |
|
||||
| | | 404 Not Found | |
|
||||
|
||||
- Be wary of using too many status codes and confusing the API user.
|
||||
- It is good to provide an additional description of the status code in the body of the HTTP Response. For example:
|
||||
- Request: method GET /pets?type=feline
|
||||
- Response:
|
||||
```
|
||||
//This is an invalid request.
|
||||
{
|
||||
"message": "Invalid Pet Type please enter a valid pet category",
|
||||
}
|
||||
* Be wary of using too many status codes and confusing the API user
|
||||
* It is good to provide an additional description of the status code in the body of the HTTP Response. For example:
|
||||
* Request: method `GET /pets?type=feline`
|
||||
* Response:
|
||||
|
||||
```json
|
||||
//This is an invalid request.
|
||||
{
|
||||
"message": "Invalid Pet Type please enter a valid pet category"
|
||||
}
|
||||
```
|
||||
### Executing search, sort, filter and pagination operations
|
||||
- When you need to perform these actions, you can append the query parameters to the GET method and the API endpoint. For example, to carry out a **search** operation for a particular pet:
|
||||
- GET /pets?search=Blaze (This will search for a pet named Blaze)
|
||||
- **Pagination** helps you to manage the amount of resources you return and it is advisable to use the parameters offset and limit as shown in the example below:
|
||||
- GET /pets?offset=10&limit=20 (Return pets between 10 to 20)
|
||||
- To **sort** the list of resources we can use multiple sort parameters in the query string. For example:
|
||||
- GET /pets?sort=age_desc (Would sort the age in descending order.)
|
||||
- For **filtering** we can use one or more parameters in the query string. For example:
|
||||
- GET /pets?type=canine&age=7
|
||||
|
||||
<!-- theme: info -->
|
||||
>If too many query parameters are used in GET methods and the URL becomes too long, the server may return a ‘414 URL too long’ HTTP status. Parameters might be passed to the request body of a POST request as a solution to this challenge.
|
||||
### Executing search, sort, filter and pagination operations
|
||||
|
||||
* When you need to perform these actions, you can append the query parameters to the GET method and the API endpoint. For example, to carry out a **search** operation for a particular pet:
|
||||
|
||||
* `GET /pets?search=Blaze` (This will search for a pet named Blaze)
|
||||
|
||||
* **Pagination** helps you to manage the amount of resources you return and it is advisable to use the parameters offset and limit as shown in the example below:
|
||||
|
||||
* `GET /pets?offset=10&limit=20` (Return pets between 10 to 20)
|
||||
|
||||
* To **sort** the list of resources we can use multiple sort parameters in the query string. For example:
|
||||
|
||||
* `GET /pets?sort=age_desc` (Would sort the age in descending order.)
|
||||
|
||||
* For **filtering** we can use one or more parameters in the query string. For example:
|
||||
|
||||
* `GET /pets?type=canine&age=7`
|
||||
|
||||
> If too many query parameters are used in GET methods and the URL becomes too long, the server may return a ‘414 URL too long’ HTTP status. Parameters might be passed to the request body of a POST request as a solution to this challenge.
|
||||
|
||||
### Versioning
|
||||
|
||||
### Versioning
|
||||
It is good practice to version an API to describe the available features and resources it exposes. When this is properly done, the application consuming the API can submit explicit requests to a specific version of a feature or resource. For example, you can specify the version of the resource by means of a parameter within the query string affixed to the HTTP request: http://api.yourdomain.com/v2/pets/10/
|
||||
|
||||
|
||||
---
|
||||
|
||||
**Related Articles**
|
||||
- [Modeling Introduction](/modeling/introduction)
|
||||
- [Using the CRUD Builder](/modeling/modeling-with-openapi/using-the-crud-builder)
|
||||
- [API Models](/modeling/modeling-with-openapi/api-models)
|
||||
- [Security Schemes](/modeling/modeling-with-openapi/security-schemes)
|
||||
- [Shared Parameters and Responses](/modeling/modeling-with-openapi/shared-parameters-and-responses)
|
||||
|
||||
|
||||
@@ -1 +1,128 @@
|
||||
# Using the CRUD Builder
|
||||
|
||||
Stoplight's CRUD builder allows you to easily design and model data structures
|
||||
used by your API. The CRUD builder is especially useful for:
|
||||
|
||||
* Drafting API requests and response bodies under an API endpoint
|
||||
* Creating [models](/modeling/modeling-with-openapi/api-models) for your API
|
||||
* Creating [shared responses](/modeling/modeling-with-openapi/shared-parameters-and-responses) for
|
||||
re-use across multiple endpoints
|
||||
|
||||
There are three different methods for generating a CRUD model:
|
||||
|
||||
* Using the CRUD builder **editor**, which allows you to create data structures
|
||||
in an easy-to-use, graphical format
|
||||
|
||||
* Using the **Generate from JSON** feature, which allows you to copy and paste
|
||||
an existing JSON document into the CRUD builder to have a model automatically
|
||||
generated for you
|
||||
|
||||
* Using the **Raw Schema** editor, if you would prefer to modify the data
|
||||
structure with raw JSON
|
||||
|
||||
While each method can be used individually, you will most likely find yourself
|
||||
using a combination of all three while drafting API endpoints, models, and
|
||||
shared responses.
|
||||
|
||||
## Using the Editor
|
||||
|
||||
<!-- FIXME: Insert GIF of using the editor, creating objects, setting their type, etc -->
|
||||
|
||||
We created the CRUD builder editor to make data structure creation as simple as
|
||||
possible. You can find the CRUD builder editor under the **Editor** tab under
|
||||
any request, response, or model view.
|
||||
|
||||
To start utilizing the editor:
|
||||
|
||||
* Click the **+** (plus) icon next to the root **object** to start adding fields
|
||||
to the data structure. The plus icon can also be used on nested objects to
|
||||
create a hierarchy of arbitrarily-nested data structures
|
||||
|
||||
* Set the **field name** (or _key_) of a data field by clicking the text label
|
||||
to the left of the newly-created field. Field names can be composed of any
|
||||
alpha-numeric characters, but can only be specified once. You will receive an
|
||||
error if you try to re-use field names multiple times on the same level
|
||||
(though they can be re-used on nested objects)
|
||||
|
||||
* Set the **type** of a field by clicking the _string_ label to the right of
|
||||
the field name. The default type for a newly-created field is 'string',
|
||||
however other types include:
|
||||
|
||||
* objects (for nesting objects)
|
||||
* arrays
|
||||
* numbers
|
||||
* integers
|
||||
* booleans
|
||||
* nulls
|
||||
* [references](/modeling/json-best-practices/reducing-duplication-with-refs)
|
||||
|
||||
Field types can also include _Combination Types_, which include 'allOf',
|
||||
'oneOf', and 'anyOf'. These special types allow for object inheritance from
|
||||
other data structures and models, and discussed in more detail
|
||||
[here](/modeling/json-best-practices/object-inheritance).
|
||||
|
||||
* Optionally, you can set extra validations on the field, for example:
|
||||
|
||||
* **Enumerations** (or _enums_ for short) allow you to restrict the contents
|
||||
of the field to be specific values. For example, if you are creating a
|
||||
'color' field of type string, you may want to restrict the strings used in
|
||||
that field to specific colors (red, blue, green, etc).
|
||||
|
||||
* **Format** allows for validating the field value is of a specific format. A
|
||||
few common format validations include: date, time, date-time, URI, and
|
||||
email.
|
||||
|
||||
In addition to the validations listed above, there are also per-type
|
||||
validations that can be used depending on the type of the field. For example,
|
||||
string validations include setting a minimum/maximum length and regex pattern.
|
||||
For numbers, you can set minimum/maximum values and even validate that the
|
||||
numeric value is a multiple.
|
||||
|
||||
* Optionally, you can specify a field as **required**, which ensures that the
|
||||
field is present in all requests (and an error is thrown otherwise).
|
||||
|
||||
## Generating from JSON
|
||||
|
||||
If you have a pre-existing JSON document that you would like to convert to a
|
||||
Stoplight data structure, the **Generate from JSON** button available towards
|
||||
the top of the CRUD editor allows you to do just that.
|
||||
|
||||
<!-- FIXME: Insert GIF of the generate from json feature -->
|
||||
|
||||
To start:
|
||||
|
||||
* Click the **Generate from JSON** button, opening a text input
|
||||
|
||||
* Either paste or write the contents of the desired JSON object into the text input
|
||||
|
||||
* Click the **Generate** button
|
||||
|
||||
And that's it! The JSON document will automatically be converted into a
|
||||
Stoplight data structure, able to be included as models, request/response
|
||||
bodies, and shared responses.
|
||||
|
||||
> The result of a **Generate from JSON** can also be edited using the CRUD
|
||||
> editor once it is generated, so you can still modify and add validations
|
||||
> afterwards.
|
||||
|
||||
## Editing the Raw JSON Schema
|
||||
|
||||
<!-- FIXME: Insert GIF of clicking the 'raw schema' button and editing the json -->
|
||||
|
||||
While not for the faint hearted, you can also edit the raw JSON schema directly
|
||||
if you are familiar with the format, or have a pre-existing JSON schema
|
||||
representation of your data structure.
|
||||
|
||||
To edit the raw JSON schema, click the **Raw Schema** tab next to the **Editor**
|
||||
tab. This will open a text box with the JSON schema of the current object. From
|
||||
there, you can either edit or copy and paste contents directly into the text box
|
||||
to update the data structure.
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [API Modeling Overview](/modeling/introduction)
|
||||
* [Shared Parameters and Responses Overview](/modeling/modeling-with-openapi/shared-parameters-and-responses)
|
||||
* [References Overview](/modeling/json-best-practices/reducing-duplication-with-refs)
|
||||
* [Object Inheritance](/modeling/json-best-practices/object-inheritance)
|
||||
|
||||
@@ -7,10 +7,9 @@
|
||||
- Similar features can be created as reusable definitions and utilized with references
|
||||
- These definitions can be hosted on the same server as your OAS file or on a different server
|
||||
- You can reference a definition hosted at any location or server
|
||||
- Apart from defining reusable definitions, you can also define reusable responses and parameters. You can store your reusable definitions, responses, and parameters in a common library.
|
||||
- Apart from defining reusable definitions, you can also define reusable responses and parameters. You can store your reusable definitions, responses, and parameters in a common library
|
||||
|
||||
<!-- theme: info -->
|
||||
>Key Terms: A definition is a named schema object. A reference is a path to a declaration within an OAS file.
|
||||
>Key Terms: A definition is a named schema object. A reference is a path to a declaration within an OAS file
|
||||
|
||||
## How to Reference a Definition
|
||||
To invoke a reference to a definition, use the **$ref** keyword. For example:
|
||||
@@ -125,5 +124,9 @@ Bad
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
```
|
||||
---
|
||||
**Related Articles**
|
||||
- [Referencing Another API Spec](/modeling/modeling-with-openapi/referencing-another-api-spec)
|
||||
- [JSON Introduction](/modeling/json-best-practices/introduction)
|
||||
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
# Generating Schema
|
||||
|
||||
## What
|
||||
- A schema is metadata that defines the structure, properties, and relationships between data. It also defines the rules that must be adhered to and is usually in the form of a document.
|
||||
- A structured approach is always recommended for handling and manipulating data.
|
||||
- The "$ref" keyword is used to reference a schema.
|
||||
- A schema is metadata that defines the structure, properties, and relationships between data. It also defines the rules that must be adhered to and is usually in the form of a document
|
||||
- A structured approach is always recommended for handling and manipulating data
|
||||
- The "$ref" keyword is used to reference a schema
|
||||
|
||||
## Why
|
||||
- A schema definition makes the process of handling data more structured.
|
||||
- The process of validation and handling user input errors can be imprioved through the use of schemas.
|
||||
- Schemas encourage the 'single source of truth' (single place to update a definition) concept which, among other things, makes it easier to create and maintain endpoints.
|
||||
- A schema definition makes the process of handling data more structured
|
||||
- The process of validation and handling user input errors can be imprioved through the use of schemas
|
||||
- Schemas encourage the 'single source of truth' (single place to update a definition) concept which, among other things, makes it easier to create and maintain endpoints
|
||||
|
||||
## Best Practices
|
||||
- It is advisable to always use a schema when you define and implement your API.
|
||||
- Use schemas to rapidly extract titles, descriptions, and samples for easy API documentation.
|
||||
- It is advisable to always use a schema when you define and implement your API
|
||||
- Use schemas to rapidly extract titles, descriptions, and samples for easy API documentation
|
||||
|
||||
## JSON Schema
|
||||
- JSON (Javascript Object Notation) is a popular, human readable data format that is easy to parse at the server or client side.
|
||||
- JSON Schema is a standard that contains information about the properties of a JSON object that can be used by an API. It also helps validate the structure of JSON data.
|
||||
- JSON (Javascript Object Notation) is a popular, human readable data format that is easy to parse at the server or client side
|
||||
- JSON Schema is a standard that contains information about the properties of a JSON object that can be used by an API. It also helps validate the structure of JSON data
|
||||
-The properties include: name, title, type etc.
|
||||
- JSON Schema Specification is divided into three parts:
|
||||
- **JSON Schema Core**: describes the basic foundation of JSON Schema
|
||||
- **JSON Schema Validation**: describes methods that define validation constraints. It also describes a set of keywords that can be used to specify validations.
|
||||
- **JSON Hyper-Schema**: an extension of the JSON Schema Specification that defines hyperlink, images, and hypermedia-related keywords.
|
||||
- **JSON Schema Validation**: describes methods that define validation constraints. It also describes a set of keywords that can be used to specify validations
|
||||
- **JSON Hyper-Schema**: an extension of the JSON Schema Specification that defines hyperlink, images, and hypermedia-related keywords
|
||||
|
||||
## Example
|
||||
Assume you have an API that requires data provided in the format below:
|
||||
|
||||
@@ -1,25 +1,63 @@
|
||||
# Introduction to Objects in API Document Structure
|
||||
# Introduction to JSON
|
||||
|
||||
- An OpenAPI document is a document that describes an API and conforms to the OpenAPI Specification. These documents can be in YAML or JSON format.
|
||||
- Your OpenAPI document can be a single document or a combination of several associated resources which use the $ref syntax to reference the interrelated resources.
|
||||
## What is JSON?
|
||||
|
||||
## Primitive Data Objects Supported in an OpenAPI Document
|
||||
JSON (short for JavaScript Object Notation) is a syntax used to represent data
|
||||
structures in a simple, easy-to-read textual format. JSON is ubiquitous
|
||||
throughout the computing industry, and has become the de-facto data format of
|
||||
the Web.
|
||||
|
||||
- integer (int32 and int64)
|
||||
- number (float and double)
|
||||
- string
|
||||
- byte
|
||||
- binary
|
||||
- boolean
|
||||
- date
|
||||
- dateTime
|
||||
- password
|
||||
If you have never seen JSON before, here is a small demonstration using JSON to
|
||||
describe a (fictional) person:
|
||||
|
||||
## Additional OpenAPI Objects
|
||||
```json
|
||||
{
|
||||
"firstName": "Lando",
|
||||
"lastName": "Calrissian",
|
||||
"title": "Baron Administrator",
|
||||
"address": {
|
||||
"streetAddress": "123 Betrayal Dr",
|
||||
"city": "Cloud City",
|
||||
"planet": "Bespin"
|
||||
},
|
||||
"homeworld": "Socorro",
|
||||
"currentLocation": null
|
||||
}
|
||||
```
|
||||
|
||||
- **Info Object**: describes the API's title, description (optional), and version metadata. It also supports other details such as contact information, license, and terms of service.
|
||||
- **Server Object**: identifies the API server and base URL. You can identify a single server or multiple servers and describe them using a description field. All API paths are relative to the URL of the server, for example, "/pets" when fully dilineated, may describe "http://api.hostname.com/pets."
|
||||
- **Paths Object**: outlines relative paths to individual endpoints within your API and the operations or HTTP methods supported by the endpoints. For example, "GET/pets" can be used to return a list of pets.
|
||||
- **Parameter Object**: describes a single operation parameter. Operations can have parameters passed through by several means such as: URL path, query string, cookies, and headers. Parameters can be marked as mandatory or optional, you can also describe the format, data type, and indicate its depreciation status.
|
||||
- **Request body object**: describes body content and media type. It is often used with insert and update operations (POST, PUT, PATCH).
|
||||
- **Response object**: describes the expected response which can be referenced using the $ref syntax or described within the document. It associates an HTTP response code to the expected response. Examples of HTTP status codes incldue the 200-OK or 404-Not Found codes. [Click here for more information on HTTP Response codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
|
||||
## Why JSON?
|
||||
|
||||
There are many benefits to using JSON, some of which include:
|
||||
|
||||
* It can be used to represent a wide array of objects in a simple and
|
||||
easy-to-read format, making it useful for just about anything
|
||||
|
||||
* It is widely used and supported across web browsers and programming languages,
|
||||
making it very easy to develop for
|
||||
|
||||
* It is easy to read and write by humans (as well as computers), making it a
|
||||
great choice for specifications like [OpenAPI](https://github.com/OAI/OpenAPI-Specification#the-openapi-specification)
|
||||
|
||||
* It is a subset of another syntax called
|
||||
[YAML](https://en.wikipedia.org/wiki/YAML). Documents written in JSON can also
|
||||
be written in YAML, so either format can be used to write OpenAPI documents
|
||||
|
||||
* It can be used to link files together through [JSON
|
||||
references](/modeling/introduction/modeling-with-openapi/referencing-another-api-spec), making it easy to break up large documents
|
||||
into smaller, more focused documents
|
||||
|
||||
Whether you are modeling an API, creating a Prism Collection, or writing
|
||||
documentation in Stoplight, behind the scenes you are actually updating a JSON
|
||||
document.
|
||||
|
||||
> You can see the underlying JSON document of any object being updated in
|
||||
> Stoplight using the editor's **Code** button at the top of the screen.
|
||||
|
||||
---
|
||||
|
||||
**Related Articles**
|
||||
|
||||
* [JSON Overview - Wikipedia](https://en.wikipedia.org/wiki/JSON)
|
||||
* [YAML Overview - Wikipedia](https://en.wikipedia.org/wiki/YAML)
|
||||
* [OpenAPI Specification Format Reference](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#format)
|
||||
* [Referencing Another API Specification](/modeling/modeling-with-openapi/referencing-another-api-spec)
|
||||
|
||||
@@ -1 +1,30 @@
|
||||
# Modeling Introduction
|
||||
|
||||
## What is API Design?
|
||||
|
||||
Designing (also known as Modeling) your API involves describing all of the inputs and outputs across the footprint of your entire service. Your API design will answer questions like:
|
||||
|
||||
- What are the different resources and operations available in your API?
|
||||
- How does your API authenticate requests?
|
||||
- What are the different data models assoicated with your service?
|
||||
- How does your API handle errors?
|
||||
|
||||
## How does it fit into Stoplight?
|
||||
|
||||
The Stoplight design module is where you and your team will maintain the single source of truth that describes the inputs and outputs of your API.
|
||||
|
||||
Once you have your API described in the Stoplight design module, you can:
|
||||
|
||||
- Publish all or part of your API in our Documentation service
|
||||
- Create API tests from your designs
|
||||
- Send requests to your API to debug it
|
||||
- ...and much more
|
||||
|
||||
## Getting Started
|
||||
|
||||
There are a few ways to get started designing your API with the Stoplight design module, depending on how developed your API is:
|
||||
|
||||
- Create an API from scratch [Using the CRUD Builder](/modeling/modeling-with-openapi/using-the-crud-builder)
|
||||
- [Reference another API Spec](/modeling/modeling-with-openapi/referencing-another-api-spec)
|
||||
- [Send HTTP Requests](/modeling/modeling-with-openapi/sending-http-requests) to an existing API Spec
|
||||
- [Validate your API Spec](/modeling/modeling-with-openapi/validating-your-api-sec)
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
* 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).
|
||||
[here](/modeling/modeling-with-openapi/api-models).
|
||||
|
||||
* **Inheritance** is when a model derives its properties from another model.
|
||||
|
||||
@@ -32,8 +32,6 @@
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -141,3 +139,9 @@ properties), the derived SUV model will have the following JSON properties:
|
||||
}
|
||||
}
|
||||
```
|
||||
---
|
||||
**Related Articles**
|
||||
- [JSON Introduction](/modeling/json-best-practices/introduction)
|
||||
- [Adding Validations](/modeling/json-best-practices/adding-validations)
|
||||
- [Reducing Duplication with $refs](/modeling/json-best-practices/reducing-duplication-with-refs)
|
||||
- [Generating Schemas](/modeling/json-best-practices/generating-schemas)
|
||||
|
||||
@@ -5,7 +5,6 @@
|
||||
## What
|
||||
OpenAPI validation is the process of verifying the underlying OpenAPI file syntax by making sure it conforms to the [OpenAPI Specification requirements](https://github.com/OAI/OpenAPI-Specification#the-openapi-specification) provided by the [OpenAPI Initiative](https://www.openapis.org/). Stoplight immediately validates any changes done to a spec to ensure they are in the correct format prior to being saved.
|
||||
|
||||
<!-- theme: info -->
|
||||
> Stoplight currently supports the OpenAPI v2 specification. We are working on support for OpenAPI v3, and should have more information in the coming months.
|
||||
|
||||
## Why
|
||||
@@ -18,7 +17,6 @@ OpenAPI validation is the process of verifying the underlying OpenAPI file synta
|
||||
- Assign a default value to optional properties or parameters with missing values. The server will use the default value when a value is missing or not provided
|
||||
- You can use the keyword **ReadOnly** to designate a property that can be sent in a response and should not be sent in a request
|
||||
|
||||
<!-- theme: info -->
|
||||
> Using a default value is not recommended when a property or parameter is mandatory
|
||||
|
||||
- An API can comsume different media types, the accepted media type can be specified using the **consume** keyword at the operational level or root level to define acceptable media types. For example:
|
||||
@@ -31,8 +29,13 @@ consumes:
|
||||
application/json
|
||||
```
|
||||
- An HTTP response containing a user friendly error description is useful when validation fails
|
||||
***
|
||||
|
||||
**Related**
|
||||
|
||||
* [File Validation](../editor/file-validation.md)
|
||||
---
|
||||
**Related Articles**
|
||||
- [Modeling Introduction](/modeling/introduction)
|
||||
- [Using the CRUD Builder](/modeling/modeling-with-openapi/using-the-crud-builder)
|
||||
- [API Operations](/modeling/modeling-with-openapi/api-operations)
|
||||
- [API Models](/modeling/modeling-with-openapi/api-models)
|
||||
- [Security Schemes](/modeling/modeling-with-openapi/security-schemes)
|
||||
|
||||
|
||||
@@ -1 +1,42 @@
|
||||
# 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](/documentation/referencing-other-data-sources)
|
||||
* [API Models](/modeling/modeling-with-openapi/api-models)
|
||||
* [Shared Parameters and Responses](/modeling/modeling-with-openapi/shared-parameters-and-responses)
|
||||
|
||||
|
||||
@@ -1,54 +1,92 @@
|
||||
# API Security Schemes
|
||||
API security schemes protect your API resources by authenticating apps or users that consume your API. There are a number of standard authentication protocols you can pick from and each has their own strengths and weaknesses. To help you get started, the section below outlines some common schemes in use.
|
||||
|
||||
API security schemes protect your API resources by authenticating apps or users
|
||||
that consume your API. There are a number of standard authentication protocols
|
||||
you can pick from, each with their own strengths and weaknesses. To help you get
|
||||
started, the section below outlines some common schemes in use.
|
||||
|
||||
## Authentication Schemes
|
||||
|
||||
### Basic API Authentication
|
||||
- Easy to implement
|
||||
- Entails sending encoded username and password details
|
||||
- Usually bundled with standard framework or language library
|
||||
- Used with HTTPS, TLS or SSL
|
||||
- Can be combined with other security methods
|
||||
- **Note**: this method is susceptible to hijacks and man-in-the-middle attacks
|
||||
|
||||
* Easy to implement, and supported by nearly all web servers
|
||||
* Entails sending base-64 encoded username and passwords
|
||||
* Usually bundled with standard framework or language library
|
||||
* Should not be used without SSL, or some other data-in-transit encryption mechanism
|
||||
* Can easily be combined with other security methods
|
||||
|
||||
> **Note**, basic authentication is susceptible to hijacks and man-in-the-middle
|
||||
> attacks when no encryption is in use. Due to this limitation, this method of
|
||||
> authentication is only recommended when paired with SSL.
|
||||
|
||||
### OAuth1.0 (Digest Scheme)
|
||||
- Popular, tested, secure, signature driven, protocol
|
||||
- Uses cryptographic signature, which is a mix of token secret, nonce, and other request based information.
|
||||
- Can be used with or without SSL
|
||||
|
||||
* Popular, tested, secure, signature driven, protocol
|
||||
* Uses cryptographic signature, which is a mix of token secret, nonce, and other request based information
|
||||
* Can be used with or without SSL
|
||||
|
||||
### OAuth2 (Bearer Token Scheme)
|
||||
- The current OAuth2 specification eliminates need for cryptographic signatures, passwords, and usernames.
|
||||
- OAuth2 works with authentication scenarios called flows, these flows include:
|
||||
- Authorization Code flow
|
||||
- Implicit flow
|
||||
- Resource Owner Password flow
|
||||
- Client Credentials flow
|
||||
- The OAuth 2.0 server will distribute access tokens that a client application will use to access protected resources.
|
||||
- [Additional Information on OAuth2.0](https://tools.ietf.org/html/rfc6749)
|
||||
|
||||
* The current OAuth2 specification eliminates need for cryptographic signatures, passwords, and usernames
|
||||
* OAuth2 works with authentication scenarios called flows, these flows include:
|
||||
* Authorization Code flow
|
||||
* Implicit flow
|
||||
* Resource Owner Password flow
|
||||
* Client Credentials flow
|
||||
* The OAuth 2.0 server will distribute access tokens that a client application will use to access protected resources
|
||||
|
||||
> Additional Information on OAuth2.0 can be found [here](https://tools.ietf.org/html/rfc6749).
|
||||
|
||||
### OpenID Connect Discovery
|
||||
- OpenID Connect Discovery (OIDC) is based on the OAuth 2.0 protocol.
|
||||
- Uses a sign-in flow that permits user authentication and information access by a client app.
|
||||
- The user information is encoded via a secure JSON Web Token (JWT).
|
||||
- [Additional Information on OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
## Best Practices
|
||||
### Implementing IDs
|
||||
Unique User IDs should be distinctive but not easy to decipher.
|
||||
- Example: using ‘a12bc3’ is weak when compared to an ID that reads ‘09dgf659sjf038eyr3367dhrt34j5’. Avoid using auto increment for your Unique User IDs to reduce the likelihood of a security breach.
|
||||
### Sensitive Information in HTTP Request
|
||||
Ensure that your API will not expose important information such as password, API keys, and security tokens in the URL. For example, this URL is bad because it contains an API key:
|
||||
- /baseurl/<uid>q=?apiKey=2123223223
|
||||
### API Keys
|
||||
Reduce the likelihood of exposing your API keys by keeping them in a file or storage mechanism that is accessible by the owner.
|
||||
- **Note**: API Keys can be duplicated or lost so it is important to use other security measures apart from API keys. Consider encryption to make your API keys more secure.
|
||||
|
||||
### Validation
|
||||
It is beneficial to validate your inputs and access to resources using robust parsers. Parsing requests can help verify the validity of user requests. API designers can perform an implicit input validation to ensure the user inputs data with permitted characters, right syntax and character length. Using regular expressions can also help validate string inputs. If a request exceeds the defined limit, you can return a ‘413 Request Entity Too Large’ response code.
|
||||
* OpenID Connect Discovery (OIDC) is based on the OAuth 2.0 protocol
|
||||
* Uses a sign-in flow that permits user authentication and information access by a client app
|
||||
* The user information is encoded via a secure JSON Web Token (JWT)
|
||||
|
||||
### Audit log
|
||||
Create audit logs before and after security related events. You can also log validation errors to detect patterns or potential attacks.
|
||||
### HTTP Status Codes
|
||||
Use status codes and proper error handling techniques for incoming requests to identify probable security risks.
|
||||
- [Additional Information on HTTP Status and Error Codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
|
||||
> Additional Information on OpenID Connect Discovery can be found [here](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Sensitive Information in HTTP Request URLs
|
||||
|
||||
Ensure that your API will not expose important information such as passwords,
|
||||
API keys, and security tokens in the URL. For example, this URL can be
|
||||
considered insecure because it contains an API key as a query parameter:
|
||||
|
||||
```
|
||||
/baseurl/<uid>q=?apiKey=2123223223
|
||||
```
|
||||
|
||||
### API Keys
|
||||
|
||||
Reduce the likelihood of exposing your API keys by keeping them in a file or
|
||||
storage mechanism that is accessible only by the owner.
|
||||
|
||||
> **Note**, API Keys can be duplicated or lost so it is important to use other
|
||||
> security measures apart from API keys. Consider encryption to make your API
|
||||
> keys more secure.
|
||||
|
||||
### Validation
|
||||
|
||||
It is beneficial to validate your inputs and access to resources using robust
|
||||
parsers. Parsing requests can help verify the validity of user requests. API
|
||||
designers can perform an implicit input validation to ensure the user inputs
|
||||
data with permitted characters, right syntax, and character length. Using
|
||||
regular expressions can also help validate string inputs.
|
||||
|
||||
### Audit log
|
||||
|
||||
Create audit logs before and after security related events. You can also log
|
||||
validation errors to detect patterns or potential attacks.
|
||||
|
||||
### HTTP Status Codes
|
||||
|
||||
Use status codes and proper error handling techniques for incoming requests to
|
||||
identify potential security risks.
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Additional Information on HTTP Status and Error Codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
|
||||
* [API Operations](/modeling/introduction/modeling-with-openapi/api-operations)
|
||||
|
||||
@@ -1 +1,34 @@
|
||||
# Sending HTTP Requests
|
||||
|
||||
<!---Gif of simple request plus extending spec--->
|
||||
|
||||
## What
|
||||
|
||||
Use the HTTP Request Maker to send requests to the endpoints defined in your specification, extend your specification with new endpoints, or send a request to any endpoint.
|
||||
|
||||
## How
|
||||
|
||||
1. Click **HTTP** in the top tool bar located above the editor.
|
||||
2. Select a **method** from the first dropwdown.
|
||||
3. Choose a **path** from the next dropdown, or enter any **valid API endpoint**.
|
||||
4. If the variables tab is present, fill in any required values
|
||||
5. Use the tabbed menu to add headers, query params, request body information, or authentication.
|
||||
6. Click **send** and view the results.
|
||||
|
||||
> #### Bonus
|
||||
>
|
||||
> Click **Extend Spec** to append or alter your specification using the information supplied in the request maker.
|
||||
|
||||
## Additional Notes
|
||||
|
||||
* The Code Generation tab can but used to view your request in another language so it can be sent through other means.
|
||||
|
||||
* If a path or endpoint is selected from your current specification, the tabbed menu will prepopulate with any parameters defined in the spec.
|
||||
|
||||
* To add variable path parameters, wrap the parameter name in the path in curly braces like so `/path/{param}` and then fill in the value in the Variables tab.
|
||||
|
||||
* To use environment variables in your request, enter `{$$.env.variable_name}` as the value and the populated value can be viewed or changed in the variables tab.
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
[Using Environment Variables](./variables-environment.md)
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# Create An Organization
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Organizations are great for grouping people, data, and billing together in one convenient location
|
||||
Organizations are great for grouping people, data, and billing together in one convenient location.
|
||||
|
||||
## Who
|
||||
* Only the Billing **Owner** or Organization **Administrator** can create Organizations
|
||||
* Only the Billing **Owner** or Organization **Administrators** can create Organizations
|
||||
|
||||
## How
|
||||
1. Click on **+ New** to the right of Organizations
|
||||
@@ -16,3 +16,13 @@
|
||||
4. Add member by email (optional)
|
||||
* Input email accounts to add other members to your organization
|
||||
* You can also do this later
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Create a Project](/platform/projects/creating-a-project)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
- [Delete an Organization](/platform/organizations/delete-org)
|
||||
|
||||
@@ -1,22 +1,33 @@
|
||||
# Customize Your Organization
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Want to modify your Organization? In Stoplight you can modify your Organization's:
|
||||
* Name
|
||||
* Org Path
|
||||
* Add a Description
|
||||
* Add an Org Image
|
||||
|
||||
Want to modify your Organization? In Stoplight you can modify your Organization's:
|
||||
* Name
|
||||
* Org Path
|
||||
* Add a Description
|
||||
* Add an Org Image
|
||||
|
||||
## Who
|
||||
* Only an Organization **Owner** or **Administrator** can modify Organizations
|
||||
* Only an Organization **Owner** or **Administrators** can modify Organizations
|
||||
|
||||
## How
|
||||
1. From the homepage, select the **Organization** you would like to modify
|
||||
2. Select the **Settings** tab
|
||||
3. Input a **Name**
|
||||
4. Input a **Path**
|
||||
5. Input a quick sentence about your organization
|
||||
6. Select an **image** file for your Org
|
||||
5. Input a quick sentence about your organization (optional)
|
||||
6. Select an **image** file for your Org (optional)
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Customize a Team](/platform/organizations/teams/create-team)
|
||||
- [Create an Organization](/platform/organizations/create-org)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
- [Delete an Organization](/platform/organizations/delete-org)
|
||||
|
||||
|
||||
@@ -1,11 +1,15 @@
|
||||
# Delete an Organization
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Deleting an organization is easy peasy, but once you delete an Org, there is no going back. Please be certain.
|
||||
|
||||
Deleting an organization is easy peasy, but once you delete an Org, there is no going back. Please be certain.
|
||||
|
||||
## Who
|
||||
* Only the Organization’s **Owner**
|
||||
|
||||
Only the Organization’s **Owner** can delete
|
||||
|
||||
## How
|
||||
1. From the homepage, select the **Organization** you would like to delete
|
||||
2. Select the **Settings** tab
|
||||
@@ -13,3 +17,12 @@
|
||||
4. Click on **Delete this Org**
|
||||
5. Confirm the deletion by clicking okay on the proceeding popup
|
||||
6. Wipe the tears from your eyes and say goodbye
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Delete a Team](/platform/organizations/teams/delete)
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Invite People to an Organization
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Adding people to your Organization is the first step towards collaboration within Stoplight
|
||||
Adding people to your Organization is the first step towards collaboration within Stoplight.
|
||||
|
||||
## Who
|
||||
* Only an Organization **Owner** or **Administrator** can invite people to an Organization
|
||||
@@ -15,3 +15,13 @@
|
||||
4. In the popup that appears input email addresses or usernames
|
||||
5. Hit **enter** to add them to your list
|
||||
6. Once completed, click the **Invite** button
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Invite People & Teams](/platform/projects/invite-people)
|
||||
- [Add People to a Team](/platform/organizations/teams/add-people)
|
||||
- [Create an Organization](/platform/organizations/create-org)
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Remove People From Your Organization
|
||||
# Remove People from Your Organization
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Removing a person for your organization is as easy as 123...4...5...6
|
||||
@@ -15,3 +15,12 @@
|
||||
4. To the right of the person’s name, click on the **dropdown arrow** to the left of the person’s role
|
||||
5. In the dropdown menu that appears, select **Remove Member**
|
||||
6. Click **Okay** in the popup prompt
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Remove People from a Team](/platform/organizations/teams/remove-people)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
# Organization Member Roles and Permissions
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Roles and Permissions for members of Organizations can be managed and modified within Stoplight to control access to the Organization's functions and features
|
||||
* There are 3 Roles:
|
||||
* **Owner**
|
||||
* Owners can update the org, its connections, and its members
|
||||
* Has access to Billing and Organization Settings
|
||||
* **Administrator**
|
||||
* Admins can update the org, its connections, and its members
|
||||
* **Member**
|
||||
* Members can update the org and its connections. They can view its members
|
||||
Roles and Permissions for members of Organizations can be managed and modified within Stoplight to control access to the Organization's functions and features.
|
||||
* There are 3 Roles:
|
||||
* **Owner**
|
||||
* Owners can update the org, its connections, and its members
|
||||
* Has access to Billing and Organization Settings
|
||||
* **Administrator**
|
||||
* Admins can update the org, its connections, and its members
|
||||
* **Member**
|
||||
* Members can update the org and its connections. They can view its members
|
||||
|
||||
## Who
|
||||
* Only an Organization **Owner** or **Administrator** can modify roles and permissions
|
||||
@@ -21,3 +21,13 @@
|
||||
3. Find the person you would like modify
|
||||
4. To the right of their name click on the **down carrot** button to the left of the person’s role
|
||||
5. In the dropdown menu select the desired role with accompanying permissions
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Team Member Roles and Permissions](/platform/organizations/teams/roles)
|
||||
- [Change a Project Member's Role](/platform/projects/change-a-members-role)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
|
||||
|
||||
@@ -1,12 +1,14 @@
|
||||
# Transfer Primary Ownership of Your Organization
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* You can promote another Member of your Organization to the role of Owner
|
||||
* You can only transfer ownership to a Member of the Organization
|
||||
You can promote another Member of your Organization to the role of Owner
|
||||
* You can only transfer ownership to a Member of the Organization
|
||||
|
||||
## Who
|
||||
* Only the Organization **Owner** can transfer ownership of an Organization
|
||||
|
||||
## How
|
||||
1. From the homepage select the **Organization** you wish to modify
|
||||
2. Select **People** from the tabs bar
|
||||
@@ -15,3 +17,12 @@
|
||||
5. From the dropdown menu that expands, select **Owner**
|
||||
6. You will then be asked to confirm your selection in a popup window
|
||||
7. Click **Ok**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
|
||||
|
||||
@@ -3,28 +3,34 @@
|
||||

|
||||
|
||||
## What
|
||||
* You can invite people to a Project to grant them read or read/write permissions
|
||||
* There are three tiers of read/write permissions
|
||||
* **Admin Access**: Upper level permissions that allow you to:
|
||||
* Read/Write
|
||||
* Invite and Manage Members and Teams
|
||||
* Manage Project Settings
|
||||
* Delete the project
|
||||
* **Write Access**: Mid-level permissions that allow you to:
|
||||
* Read/Write
|
||||
* **Read Access**: Low-level permissions that allow you to:
|
||||
* Read
|
||||
You can invite people to a Project to grant them read or read/write permissions. There are three tiers of read/write permissions:
|
||||
* **Admin Access**: Upper level permissions that allow you to:
|
||||
* Read/Write
|
||||
* Invite and Manage Members and Teams
|
||||
* Manage Project Settings
|
||||
* Delete the project
|
||||
* **Write Access**: Mid-level permissions that allow you to:
|
||||
* Read/Write
|
||||
* **Read Access**: Low-level permissions that allow you to:
|
||||
* Read
|
||||
|
||||
|
||||
## Who
|
||||
* Only the Organization **Owner** and Org and/or Project **Administrators** can modify member roles
|
||||
* Only the Organization **Owner** and Organization or Project **Administrators** can modify member roles
|
||||
|
||||
<!-- theme: info -->
|
||||
>By deafult, all members of the Organization and the Project will have Read permission
|
||||
|
||||
## How
|
||||
1. From the Stoplight homepage select the **Project** you wish to modify
|
||||
2. By deafult, all members of the Organization the Project is associated with will have Read permission
|
||||
3. To invite a single member, select the **Member icon** from the far left sidebar
|
||||
* Input their username in the search bar at the top of the Member sidebar
|
||||
* Once located, press enter
|
||||
4. To invite a team, select the **Team icon** from the far left sidebar
|
||||
* Input the Team name in the search bar at the top of the Team sidebar
|
||||
* Once located, press enter
|
||||
2. Click on **Member Access Icon** or **Team Access Icon** in the far left sidebar
|
||||
3. Find the user you wish to modify in the list and select them
|
||||
4. From the **dropdown menu**, select the preferred role
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Creating a Project](/platform/projects/creating-a-project)
|
||||
- [Invite People & Teams](/platform/projects/invite-people)
|
||||
- [Make Your Project Private/Public](/platform/projects/visibility)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Team Member Roles and Permissions](/platform/organizations/teams/roles)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Creating a Project
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
Projects are the workspace of the Stoplight Platform. Projects contain:
|
||||
@@ -12,10 +12,11 @@ Projects are the workspace of the Stoplight Platform. Projects contain:
|
||||
* Mocking (Prism)
|
||||
* Markdown Editor
|
||||
|
||||
<callout>Single Point of Truth All editors are now contained within a Project </>
|
||||
<!-- theme: info -->
|
||||
>Single Point of Truth: All editors are now contained within a Project
|
||||
|
||||
## Who
|
||||
Individual users can create Personal Projects. Organizations can create Org Projects.
|
||||
Individual users can create Personal Projects. Organizations can create Organization Projects.
|
||||
|
||||
## How
|
||||
|
||||
@@ -32,3 +33,10 @@ Individual users can create Personal Projects. Organizations can create Org Proj
|
||||
4. Input a **Project Description** (optional)
|
||||
5. Select **Public** or **Private**
|
||||
6. Select **Create Project** once complete
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Invite People & Teams](/platform/projects/invite-people)
|
||||
- [Change a Project Member's Role](/platform/projects/change-a-members-role)
|
||||
- [Make Your Project Private/Public](/platform/projects/visibility)
|
||||
- [Create an Organization](/platform/organizations/create-org)
|
||||
|
||||
@@ -14,11 +14,11 @@
|
||||
* Read/Write
|
||||
* **Read Access**: Low-level permissions that allow you to:
|
||||
* Read
|
||||
|
||||
<callout>You can only invite people and Teams to a Project associated with an Organization</>
|
||||
|
||||
>You can only invite people and Teams to a Project associated with an Organization
|
||||
|
||||
## Who
|
||||
* Only the Organization **Owner** and Org and/or Project **Administrators** have invite privileges
|
||||
* Only the Organization **Owner** and Org and Project **Administrators** have invite privileges
|
||||
|
||||
## How
|
||||
1. From your Organization's homepage, select the **Project** you wish to modify
|
||||
@@ -29,3 +29,11 @@
|
||||
4. To invite a team, select the **Team icon** from the far left sidebar
|
||||
* Input the Team name in the search bar at the top of the Team sidebar
|
||||
* Once located, press enter
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Creating a Project](/platform/projects/creating-a-project)
|
||||
- [Change a Project Member's Role](/platform/projects/change-a-members-role)
|
||||
- [Make Your Project Private/Public](/platform/projects/visibility)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Add People to a Team](/platform/organizations/teams/add-people)
|
||||
|
||||
@@ -3,12 +3,25 @@
|
||||

|
||||
|
||||
## What
|
||||
* You can choose to make your Project Public or Private
|
||||
* **Private**: Only designated collaborators will be able to read it. Additionally, connections from ALL dependent entities outside of this Organization will be removed
|
||||
* **Public**: Anyone can read it
|
||||
|
||||
You can choose to make your Project Public or Private
|
||||
* **Private**: Only designated collaborators will be able to read it. Additionally, connections from ALL dependent entities outside of this Organization will be removed
|
||||
* **Public**: Anyone can read it
|
||||
|
||||
## Who
|
||||
* Only the Organization **Owner** and Org and/or Project **Administrator** can modify
|
||||
|
||||
* Only the Organization **Owner** and Org and Project **Administrator** can modify
|
||||
|
||||
## How
|
||||
|
||||
1. Select the **Project** you wish to modify
|
||||
2. Select the **gear icon** on the left hand sidebar
|
||||
3. Under **Danger Zone** Select **Public** or **Private**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Creating a Project](/platform/projects/creating-a-project)
|
||||
- [Invite People & Teams](/platform/projects/invite-people)
|
||||
- [Change a Project Member's Role](/platform/projects/change-a-members-role)
|
||||
|
||||
|
||||
|
||||
1
articles/robbins.md
Normal file
@@ -0,0 +1 @@
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Add People to a Team
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
|
||||
* Adding people to a team lets you collaborate on projects while allowing an additional level of control over permissions.
|
||||
Adding people to a team lets you collaborate on projects while allowing an additional level of control over permissions.
|
||||
|
||||
## Who
|
||||
|
||||
@@ -19,3 +19,13 @@
|
||||
5. Input the person’s email or Stoplight username in the textarea and press enter
|
||||
* Note: you can add more than one person at a time
|
||||
6. Once completed, click on the **Invite** button
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Invite People & Teams](/platform/projects/invite-people)
|
||||
- [Invite People to Organization](/platform/organizations/invite-people)
|
||||
- [Create a Team](/platform/organizations/teams/create-team)
|
||||
- [Remove People for a Team](/platform/organizations/teams/remove-people)
|
||||
- [Team Member Roles and Permissions](/platform/organizations/teams/roles)
|
||||
- [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
|
||||
|
||||
|
||||
@@ -1,9 +1,10 @@
|
||||
# Create a Team
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Teams makes it easier for Organization Members to collaborate and allows additional control over permissions
|
||||
|
||||
Teams makes it easier for Organization Members to collaborate and allows additional control over permissions.
|
||||
|
||||
## Who
|
||||
* Only an Organization **Owner** or **Administrator** can create a Team
|
||||
@@ -19,3 +20,13 @@
|
||||
* If the invited member does not already have a Stoplight account, an email will be sent with instructions on how to complete the account creation process
|
||||
4. Click **Create Team** once finished
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Creating a Project](/platform/projects/creating-a-project)
|
||||
- [Create an Organization](/platform/organizations/create-org)
|
||||
- [Add People to a Team](/platform/organizations/teams/add-people)
|
||||
- [Remove People for a Team](/platform/organizations/teams/remove-people)
|
||||
- [Team Member Roles and Permissions](/platform/organizations/teams/roles)
|
||||
- [Customize a Team](/platform/organizations/teams/create-team)
|
||||
- [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
|
||||
- [Delete a Team](/platform/organizations/teams/delete)
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Customize a Team
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
|
||||
* You can customize the Team Name, Path, and Team Description
|
||||
You can customize the Team Name, Path, and Team Description.
|
||||
|
||||
## Who
|
||||
|
||||
@@ -19,3 +19,9 @@
|
||||
* Input a new Team Name in the textarea under **Team Name**
|
||||
* Input a new Team URL in the textarea under **Path**
|
||||
* Input a new Team Description in the textarea under **Description**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Customize Your Organization](/platform/organizations/customize)
|
||||
- [Create a Team](/platform/organizations/teams/create-team)
|
||||
- [Delete a Team](/platform/organizations/teams/delete)
|
||||
|
||||
@@ -1,14 +1,22 @@
|
||||
# Delete a Team
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Want to disband your team? Here's how:
|
||||
|
||||
## Who
|
||||
* Only the Organization **Owner** or a Team **Owner** or **Administrator** can delete a team
|
||||
|
||||
## How
|
||||
1. Select the **Organization** associated with the team you wish to modify
|
||||
2. Select **Teams** from the tab bar
|
||||
3. Click on the **red X icon** located to the right of the team you wish to delete
|
||||
4. A popup will appear asking if you are sure you want to delete this team
|
||||
5. Click **Ok**
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Delete an Organization](/platform/organizations/delete-org)
|
||||
- [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
|
||||
- [Delete a Team](/platform/organizations/teams/delete)
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
# Team Member Roles and Permissions
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* Roles and Permissions for Team members can be managed and modified within Stoplight to control access to the Team’s functions and features
|
||||
* There are 3 Roles:
|
||||
* **Owner**
|
||||
* Owners can update the Team, its connections, and its collaborators. They can also update the team's settings and delete the team.
|
||||
* **Administrator**
|
||||
* Admins can update the Team, its connections, and its collaborators.
|
||||
* **Member**
|
||||
* Members can view and create projects. They can view the Team's members.
|
||||
Roles and Permissions for Team members can be managed and modified within Stoplight to control access to the Team’s functions and features.
|
||||
There are 3 Roles:
|
||||
* **Owner**
|
||||
* Owners can update the Team, its connections, and its collaborators. They can also update the team's settings and delete the team.
|
||||
* **Administrator**
|
||||
* Admins can update the Team, its connections, and its collaborators.
|
||||
* **Member**
|
||||
* Members can view and create projects. They can view the Team's members.
|
||||
|
||||
## Who
|
||||
* Only the Team **Owner** or **Administrator** can modify Roles and Permissions
|
||||
@@ -22,3 +22,10 @@
|
||||
4. To the right of the member’s name click on the **down carrot** button to the left of the person’s role
|
||||
5. In the dropdown menu select the desired role with accompanying permissions
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Change a Project Member's Role](/platform/projects/change-a-members-role)
|
||||
- [Organization Member Roles and Permissions](/platform/organizations/roles)
|
||||
- [Add People to a Team](/platform/organizations/teams/add-people)
|
||||
- [Remove People for a Team](/platform/organizations/teams/remove-people)
|
||||
- [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Remove People from a Team
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
|
||||
@@ -20,3 +20,11 @@
|
||||
6. In the dropdown menu select **Remove Member**
|
||||
7. A popup window will ask you to confirm your removal
|
||||
* Click Ok
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Remove People from Your Organizations](/platform/organizations/remove-members)
|
||||
- [Team Member Roles and Permissions](/platform/organizations/teams/roles)
|
||||
- [Customize a Team](/platform/organizations/teams/create-team)
|
||||
- [Transfer Ownership of a Team](/platform/organizations/teams/transfer-ownership)
|
||||
- [Delete a Team](/platform/organizations/teams/delete)
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
# Transfer Primary Ownership of a Team
|
||||
|
||||

|
||||

|
||||
|
||||
## What
|
||||
* You can transfer Ownership of a Team to another member of the Team
|
||||
You can transfer Ownership of a Team to another member of the Team.
|
||||
|
||||
## Who
|
||||
* Only the Team **Owner** can transfer Ownership of a Team
|
||||
|
||||
## How
|
||||
1. From the homepage select the **Organization** that is associated with the Team you wish to modify
|
||||
2. Select **Teams** from the tab bar
|
||||
@@ -14,3 +16,9 @@
|
||||
5. Click on the **down carrot** to the right of the Member’s name
|
||||
6. Select **Owner** from the dropdown menu
|
||||
7. Click **Ok** in the proceeding popup
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [Transfer Primary Ownership of an Organization](/platform/organizations/transfer-ownership)
|
||||
- [Team Member Roles and Permissions](/platform/organizations/teams/roles)
|
||||
|
||||
|
||||
94
articles/testing/continuous-integration-circle.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# Continuous Integration with CircleCI
|
||||
|
||||
Integrating Prism into your Circle CI pipeline is easy. The simplest way to get
|
||||
up and running is by using [Stoplight's Prism Docker
|
||||
image](https://hub.docker.com/r/stoplight/prism/).
|
||||
|
||||
To get started, you will need to reference the Prism Docker image in the
|
||||
`docker` section of either the `build` or `test` sections of your Circle CI
|
||||
configuration file. This file is typically located under the `.circleci`
|
||||
directory in the root of your repository.
|
||||
|
||||
When integrating Prism into a CircleCI pipeline, there are two different
|
||||
approaches:
|
||||
|
||||
* Starting Prism in the background to act as either a mock or
|
||||
contract/validation server
|
||||
* Having Prism conduct a scenario against a running server by running as a
|
||||
dedicated test step
|
||||
|
||||
## Running Prism in the Background
|
||||
|
||||
Below is a sample Circle CI configuration file (version 2) using Prism as a
|
||||
mock or contract/validation server:
|
||||
|
||||
```yaml
|
||||
version: 2
|
||||
jobs:
|
||||
build:
|
||||
docker:
|
||||
# The first image is where your commands will be run,
|
||||
# so be sure that the prism image is not first
|
||||
- image: your-normal-image:your-version
|
||||
# Customize the 'command' to fit your needs.
|
||||
- image: stoplight/prism:latest
|
||||
command: [prism, ...]
|
||||
steps:
|
||||
# Run test suite against http://localhost:4010
|
||||
...
|
||||
```
|
||||
|
||||
Once the Prism container is started, it will automatically start listening on
|
||||
`http://localhost:4010` for any open connections.
|
||||
|
||||
## Running Prism in the Foreground
|
||||
|
||||
Below is a sample Circle CI configuration file (version 2) with
|
||||
Prism conducting a scenario:
|
||||
|
||||
```yaml
|
||||
version: 2
|
||||
jobs:
|
||||
build:
|
||||
docker:
|
||||
- image: your-normal-image:your-version
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: Install prism
|
||||
command: curl https://raw.githubusercontent.com/pytlesk4/stoplight-todos/master/prism.sh | sh
|
||||
- run:
|
||||
name: Start your service
|
||||
command: ...
|
||||
background: yes
|
||||
- run:
|
||||
name: Run scenario
|
||||
command: prism conduct ...
|
||||
...
|
||||
```
|
||||
|
||||
When running `prism conduct` you can:
|
||||
|
||||
* Include the Scenario JSON on your CI server, and pass in its absolute file path
|
||||
* Pass in the absolute URL to the scenario JSON served up via HTTP
|
||||
|
||||
<!-- theme: warning -->
|
||||
|
||||
> Don't forget to pass in any required environment values with the --env command
|
||||
> line flag (or you can provide the filepath to a json file with your environment
|
||||
> variables)!
|
||||
|
||||
<!-- theme: info -->
|
||||
|
||||
> Did you know? You can find the full command to run your scenario collection
|
||||
> or individual scenarios in the Stoplight application. Click on the "Home"
|
||||
> button of a scenario under "Trigger This Collection".
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Continuous Integration Overview](./continuous-integration.md)
|
||||
* [Continuous Integration with Travis CI](./continous-integration-travis)
|
||||
* [Continuous Integration with Jenkins](./continous-integration-jenkins)
|
||||
* [Prism Docker Image](https://hub.docker.com/r/stoplight/prism/)
|
||||
92
articles/testing/continuous-integration-jenkins.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# Continuous Integration with Jenkins
|
||||
|
||||
Integrating Prism into your [Jenkins](https://jenkins.io/) pipeline is easy.
|
||||
There are two ways to get started with Jenkins:
|
||||
|
||||
* Running Prism in a pipeline step natively or using Docker
|
||||
* Using the "Stoplight Report" Jenkins Plugin
|
||||
|
||||
## Adding Prism to a Pipeline
|
||||
|
||||
To get started, you will need to either install Prism natively on the Jenkins
|
||||
system, or use the official [Stoplight Prism Docker image](https://hub.docker.com/r/stoplight/prism/).
|
||||
|
||||
When integrating Prism into a Jenkins pipeline, there are two different
|
||||
approaches:
|
||||
|
||||
* Starting Prism in the background to act as either a mock or
|
||||
contract/validation server
|
||||
* Having Prism conduct a scenario against a running server by running as a
|
||||
dedicated test step
|
||||
|
||||
### Running Prism in the Background
|
||||
|
||||
To run Prism in the background, you will need to start Prism prior to kicking
|
||||
off your tests. If running natively, use the command format:
|
||||
|
||||
```sh
|
||||
BUILD_ID=dontKillMe nohup prism mock --spec ... &
|
||||
```
|
||||
|
||||
<!-- theme: warning -->
|
||||
|
||||
> Please note that the trailing ampersand (`&`) is required
|
||||
|
||||
If running in Docker, use the format:
|
||||
|
||||
```sh
|
||||
docker run -d --rm -p 4010:4010 stoplight/prism:latest mock --spec ...
|
||||
```
|
||||
|
||||
For more information on using Prism as a test server, see [here](./overview.md).
|
||||
|
||||
### Running Prism in the Foreground
|
||||
|
||||
To run Prism in the foreground, you will call Prism like you would any other
|
||||
test step. If running natively, use the command format:
|
||||
|
||||
```sh
|
||||
prism conduct ...
|
||||
```
|
||||
|
||||
If running in Docker, use the format:
|
||||
|
||||
```sh
|
||||
docker run --rm stoplight/prism:latest prism conduct ...
|
||||
```
|
||||
|
||||
When running `prism conduct`, you can:
|
||||
|
||||
* Include the Scenario JSON on your CI server, and pass in its absolute file path
|
||||
* Pass in the absolute URL to the scenario JSON served up via HTTP
|
||||
|
||||
<!-- theme: warning -->
|
||||
|
||||
> Don't forget to pass in any required environment values with the --env command
|
||||
> line flag (or you can provide the filepath to a json file with your environment
|
||||
> variables)!
|
||||
|
||||
<!-- theme: info -->
|
||||
|
||||
> Did you know? You can find the full command to run your scenario collection
|
||||
> or individual scenarios in the Stoplight application. Click on the "Home"
|
||||
> button of a scenario under "Trigger This Collection".
|
||||
|
||||
## Using the Plugin
|
||||
|
||||
Members of the Stoplight community were kind enough to create the [Stoplight
|
||||
Report Plugin](https://github.com/jenkinsci/stoplightio-report-plugin), which is
|
||||
a Jenkins plugin that can be used to run tests with Prism. For more information
|
||||
on the plugin, see [here](https://plugins.jenkins.io/stoplightio-report).
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Jenkins Website](https://jenkins.io/)
|
||||
* [Continuous Integration Overview](./continuous-integration.md)
|
||||
* [Continuous Integration with Circle CI](./continous-integration-circle)
|
||||
* [Continuous Integration with Travis CI](./continous-integration-travis)
|
||||
* [Prism Docker Image](https://hub.docker.com/r/stoplight/prism/)
|
||||
* [Stoplight Report Plugin Homepage](https://plugins.jenkins.io/stoplightio-report)
|
||||
* [Stoplight Report Plugin Github](https://github.com/jenkinsci/stoplightio-report-plugin)
|
||||
@@ -1 +1,71 @@
|
||||
# Continuous Integration with Travis CI
|
||||
|
||||
Integrating Prism into your Travis CI pipeline is easy. The simplest way to get
|
||||
up and running is by using [Stoplight's Prism Docker
|
||||
image](https://hub.docker.com/r/stoplight/prism/).
|
||||
|
||||
To get started, you will need to make sure the `docker` service is listed under
|
||||
the `services` section of your `.travis.yml` file.
|
||||
|
||||
When integrating Prism into a Travis CI pipeline, there are two different
|
||||
approaches:
|
||||
|
||||
* Starting Prism in the background to act as either a mock or
|
||||
contract/validation server
|
||||
* Having Prism conduct a scenario against a running server by running as a
|
||||
dedicated test step (i.e. added to the `script` section)
|
||||
|
||||
## Running Prism in the Background
|
||||
|
||||
Below is a sample Travis CI configuration file using Prism as a mock or
|
||||
contract/validation server:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
- docker
|
||||
|
||||
before_install:
|
||||
# start the mock server in the background
|
||||
- docker run -d -p 127.0.0.1:4010:4010 stoplight/prism mock ...
|
||||
```
|
||||
|
||||
Once the Prism container is started, it will automatically start listening on
|
||||
`http://localhost:4010` for any open connections.
|
||||
|
||||
## Running Prism in the Foreground
|
||||
|
||||
Below is a sample Travis CI configuration file with Prism conducting a scenario:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
- docker
|
||||
|
||||
script:
|
||||
- docker run --rm -it stoplight/prism conduct ...
|
||||
```
|
||||
|
||||
When running `prism conduct` you can:
|
||||
|
||||
* Include the Scenario JSON on your CI server, and pass in its absolute file path
|
||||
* Pass in the absolute URL to the scenario JSON served up via HTTP
|
||||
|
||||
<!-- theme: warning -->
|
||||
|
||||
> Don't forget to pass in any required environment values with the --env command
|
||||
> line flag (or you can provide the filepath to a json file with your environment
|
||||
> variables)!
|
||||
|
||||
<!-- theme: info -->
|
||||
|
||||
> Did you know? You can find the full command to run your scenario collection
|
||||
> or individual scenarios in the Stoplight application. Click on the "Home"
|
||||
> button of a scenario under "Trigger This Collection".
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Continuous Integration Overview](./continuous-integration.md)
|
||||
* [Continuous Integration with Circle CI](./continous-integration-circle)
|
||||
* [Continuous Integration with Jenkins](./continous-integration-jenkins)
|
||||
* [Prism Docker Image](https://hub.docker.com/r/stoplight/prism/)
|
||||
|
||||
@@ -1 +1,92 @@
|
||||
# Continuous Integration
|
||||
|
||||
Continuous Integration (CI) is the practice of continuously merging developer
|
||||
work into a shared repository. By merging work frequently, developers can easily
|
||||
detect conflicts and stay up-to-date with other team members' changes. Since CI
|
||||
allows teams to maintain a high development velocity, testing becomes an even
|
||||
more crucial component to the development process. By constantly testing all
|
||||
changes, developers can verify that they are not breaking existing functionality
|
||||
or introducing new bugs.
|
||||
|
||||
By integrating Prism into your CI process, your development team can be certain
|
||||
that any changes made to a project do not violate an OpenAPI specification. This
|
||||
allows multiple teams with agreed-upon specifications to work independently of
|
||||
one another, while ensuring that any changes meet the specification throughout
|
||||
the lifetime of the project.
|
||||
|
||||
There are a few different approaches available when integrating Prism into a CI
|
||||
testing pipeline:
|
||||
testing with Stoplight [Scenarios](./scenarios-introduction.md),
|
||||
testing with a mock server, and
|
||||
contract testing.
|
||||
|
||||
## Testing with Scenarios
|
||||
|
||||
Stoplight [Scenarios](./scenarios-introduction.md) allows users to define
|
||||
multiple steps for testing an OpenAPI specification. Scenarios provide a similar
|
||||
function to API's as [functional test
|
||||
cases](https://en.wikipedia.org/wiki/Functional_testing) do in software
|
||||
development. Scenarios run (or "conducted") by Prism can be easily integrated
|
||||
into a CI pipeline for validating a server's implementation of a specification.
|
||||
|
||||
To run a scenario with Prism, use the `conduct` command:
|
||||
|
||||
```bash
|
||||
prism conduct my-scenario.json --spec open-api-spec.json -e "myapikey=abc123"
|
||||
```
|
||||
|
||||
For more information on Scenarios, please see [here](./scenarios-introduction.md).
|
||||
|
||||
## Testing with a Mock Server
|
||||
|
||||
Prism's mock server allows Prism to behave like a
|
||||
fully-implemented server for a provided OpenAPI specification. This form of
|
||||
testing is useful for:
|
||||
|
||||
* **Speeding Up Development Time**
|
||||
* Tests can be run locally with nothing more
|
||||
than an API specification. This allows a development team on the client or
|
||||
server side to work independently of one another.
|
||||
* **Validation Testing**
|
||||
* Ensures that a client implementation meets all of the requirements set by an
|
||||
OpenAPI specification.
|
||||
|
||||
To start a mock server with Prism, use the `mock` command:
|
||||
|
||||
```bash
|
||||
prism mock --spec open-api-spec.json
|
||||
```
|
||||
|
||||
For more information on mock testing with Prism, see [Mocking Introduction](FIXME).
|
||||
|
||||
## Contract Testing
|
||||
|
||||
Contract testing is when Prism acts as a proxy between the client and a target
|
||||
upstream server. When Prism receives a request, it forwards it to the upstream
|
||||
server and validates that the server response conforms to the provided OpenAPI
|
||||
specification. This form of testing is useful for:
|
||||
|
||||
* Verifying a _server_ implementation to ensure all _responses_ meet the
|
||||
appropriate requirements set by an OpenAPI specification
|
||||
* Verifying a _client_ implementation to ensure all _requests_ meet the
|
||||
appropriate requirements set by an OpenAPI specification
|
||||
* Augmenting existing test suites with very little extra work and almost no
|
||||
workflow changes required
|
||||
|
||||
To start a contract/validation server with Prism, use the `validate` command:
|
||||
|
||||
```bash
|
||||
prism validate --spec open-api-spec.json --upstream http://localhost:8080
|
||||
```
|
||||
|
||||
For more information on contract testing with Prism, see [Mocking Introduction](FIXME).
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Testing Overview](./overview.md)
|
||||
* [Scenarios Introduction](./scenarios-introduction.md)
|
||||
* [Continuous Integration with Circle CI](./continous-integration-circle.md)
|
||||
* [Continuous Integration with Travis CI](./continous-integration-travis.md)
|
||||
* [Continuous Integration with Jenkins](./continous-integration-jenkins.md)
|
||||
|
||||
@@ -1,37 +1,86 @@
|
||||
# Contract Testing
|
||||
|
||||
Scenarios makes it easy to incorporate your OAS / Swagger API specification into your testing process. A few benefits to doing this include:
|
||||
Scenarios makes it easier than ever to integrate your OpenAPI specification into
|
||||
your testing process. One of the easiest ways to do this is through a testing
|
||||
method called **contract testing**. Contract testing is a simple verification
|
||||
process where Stoplight verifies that the API responses match the "contract"
|
||||
within a connected OpenAPI specification.
|
||||
|
||||
- **DRY**: Don't re-create test assertions that check for what is already described in your API contract.
|
||||
- **Governance**: Quickly figure out if the API that was created actually conforms to the API design that was initially agreed upon.
|
||||
- **Sync Manager**: Your API spec is the single point of truth that describes your API. From it, you might generate documentation, sdks, mock servers, etc. Incorporating your spec into your tests makes sure that your API spec accurately represents your API over time.
|
||||
Benefits of contract testing include:
|
||||
|
||||
* **Don't Repeat Yourself**: Don't re-create test assertions that check for what
|
||||
is already described in your API specification. Let your scenario do the heavy
|
||||
lifting, validating that an API implementation matches the OpenAPI
|
||||
specification.
|
||||
|
||||
* **Governance**: Quickly figure out if an API implementation conforms to the
|
||||
OpenAPI specification that was initially agreed upon. Run a contract test
|
||||
scenario on a schedule to ensure the API never violates the specification.
|
||||
|
||||
* **Single Source of Truth**: Your API specification is the single source of
|
||||
truth that describes your API. From it, you can generate documentation, SDKs,
|
||||
mock servers, and more. Incorporating the specification into your testing
|
||||
pipeline ensures that the spec accurately represents your API implementation
|
||||
over time.
|
||||
|
||||
<!-- theme: info -->
|
||||
> If you don't have an API specification yet, you can create one using the Stoplight modeling tool!
|
||||
|
||||
## Connecting The Spec
|
||||
> If you don't have an API specification yet, you can create one using the
|
||||
> [Stoplight modeling tool](../modeling/modeling-introduction.md)!
|
||||
|
||||
The first thing you need to do to get started with contract testing is connect your API spec to the Scenarios Collection.
|
||||
## Connecting a Spec
|
||||
|
||||
1. Create a new (or open an existing) **Scenario file** in the Stoplight editor
|
||||
2. Select **Swagger/OAS Coverage** in the Scenarios menu to the left
|
||||
3. Open **Contract Test Settings**
|
||||
4. Click **+ Add Spec**
|
||||
5. Select a file from either **This Project** or an **External URL**
|
||||
6. You are all set! You can now test against an API spec.
|
||||
<!-- FIXME - Show a gif of selecting spec in coverage screen, and clicking on different endpoints -->
|
||||
|
||||
To get started with contract testing, the first thing you will need to do is
|
||||
generate a scenario from an OpenAPI specification. To get started:
|
||||
|
||||
1. Create a new (or open an existing) **scenario** in the Stoplight editor
|
||||
2. Select **Swagger/OAS Coverage** in the Scenarios menu to the left
|
||||
3. Open the **Contract Test Settings** menu
|
||||
4. Click **Add Spec**, and select an OpenAPI specification to connect
|
||||
|
||||
You are all set! Once the specification has been connected, you can
|
||||
automatically generate a contract testing scenario for your spec using the
|
||||
Coverge Report, as described below.
|
||||
|
||||
## Using the Coverage Report
|
||||
|
||||
The coverage report gives you a quick overview of which parts of the connected specs are covered by test assertions in the current Scenario Collection.
|
||||
The coverage report gives you a quick overview of which parts of the connected
|
||||
specs are covered by test assertions in the current Scenario Collection.
|
||||
|
||||
You can use the coverage report to quickly stub out a new scenario. Just click the status codes in the table matrix for the steps you want to add to your scenario (in order). Once you've added all the steps, click the "Create Scenario" button in the top right. This will create a scenario with as much setup as possible, using the connected spec for data. It will set your request body, set variables in a sensible way, automatically setup contract tests, and more.
|
||||
You can use the coverage report to quickly stub out a new scenario. To start:
|
||||
|
||||
You will likely need to tweak the resulting scenario a little bit, but this process will usually get you most of the way to a complete scenario, with contract test assertions in place!
|
||||
1. Click the **status codes** in the table matrix for the steps you want to add to
|
||||
your scenario.
|
||||
|
||||
|
||||
> Note that the order in which the endpoints are clicked
|
||||
> determines the order in which they will appear in the scenario. For example,
|
||||
> if an API object needs to be created before it can be removed, then you will
|
||||
> want to choose the 'create object' endpoint before the 'delete object'
|
||||
> endpoint.
|
||||
|
||||
2. Once all of the desired endpoints have been selected, click the **Create
|
||||
Scenario** button in the top right to generate the scenario.
|
||||
|
||||
3. You will automatically be navigated to the new scenario, complete with
|
||||
contract test assertions for each selected endpoint.
|
||||
|
||||
> You will likely need to modify the resulting scenario to fit your use case
|
||||
|
||||
## Automatic Contract Test Assertion
|
||||
|
||||
After linking your spec to the Scenario Collection, contract test assertions will be automatically added for step assertions.
|
||||
<!-- FIXME - Show a gif of running a scenario -->
|
||||
|
||||
Stoplight will look through your API specification for a operation that matches the step's HTTP method + URL, and use the response status code returned from the API to look up the JSON schema. In the example below, we are testing the 200 response schema in our API spec for the GET /todos/{todoId} endpoint.
|
||||
After linking your spec to the Scenario Collection, contract test assertions
|
||||
will be automatically added as steps within your scenario.
|
||||
|
||||
When this step is run, the HTTP response structure will be validated against the matched JSON schema from our API spec, and any errors will be added to the test results.
|
||||
When the scenario is generated, Stoplight will look through the API
|
||||
specification for an operation that matches the step's HTTP method and URL. The
|
||||
response code returned from the API is then used to look up the corresponding
|
||||
JSON schema.
|
||||
|
||||
When a contract assertion step is run, the HTTP response structure will be
|
||||
validated against the matched JSON schema from the connected API specification.
|
||||
Any validation errors will automatically be added to the test results.
|
||||
|
||||
30
articles/testing/introduction.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Introduction
|
||||
|
||||
As APIs continue to spread throughout orginzations it is more important than ever to develop a highly flexible, performant and powerful testing roadmap. We all know why testing is important you can catch bugs faster, iterate without breaking existing features faster, and ultimately deliver a higher quality product to the end user. But lets be honest for a second. Even though we think testing is important we were too busy to actually write them. Also, maintaining a test suite is tedious, right? Lastly, we all write perfect code, no need to test it, plus 10k people thought that Stackoverflow answer was useful. Very compelling arguments if APIs weren't everywhere, otherwise those arguements are the reason why people aren't using your API.
|
||||
|
||||
API testing isn't about you actually and you know this deep down becuase there is nothing more frustrating than using an API that doesn't work as advertised. Your customers will appreciate a well tested service, but customers aren't the only people who will be using your API anymore. Team members are now users and they might be distrbuted in a different time zone, having an awesome test suite means that they can quickly know if a service is working as intended. There is nothing more frustrating than looking for some obscure bug in code you didn't write and in a language you don't know.
|
||||
|
||||
API testing also isn't just about catching bugs and iterating faster. A through test suite is actually really great documentation. Not only are test a great way to understand how an API works under certain Scenarios ;), they can also be a great way to drive your actual implementation if you create them first. Test/Behavoir-driven development(TDD/BDD) forces you to think about design/requirements before actually writting any code.
|
||||
|
||||
Today microservices and serverless make easier than ever to iterate quickly which means it too easy to introduce bugs and the technical debt quickly becomes unmanageble without the proper testing solution. Teams are increasingly becoming smaller and spread out. It is no longer feasible to use slack and email to ask the most basic questions about a service. A comprehensive test suite documents how a service is used at a high level.
|
||||
|
||||
## Stoplight Scenarios
|
||||
|
||||
We engineered Scenarios from the ground up to be:
|
||||
|
||||
* **Powerful** Easily assert, capture, transform, and validate your API Spec (OpenAPI) against your actual API. And if that isn’t enough, Prism has a powerful javascript runtime.
|
||||
|
||||
* **Portable** Scenarios are described in plain JSON with a well thought out, robust specification. Use our visual editor to quickly generate and manage this JSON. Scenarios can be run from our visual tooling, or completely outside of Stoplight, on your own machines, or on your continuous integration server.
|
||||
|
||||
* **Flexible** Your APIs, your tests, your way. Scenarios only test what you want them to. They have no opinion about your architecture (Monolithic vs Microservices), company structure (in house vs distributed), development lifecycle (production vs TDD), and your environment (development vs staging vs production).
|
||||
|
||||
* **Fast** Time can’t be slowed down, and we can’t give it back to you. Creating tests should be quick, and waiting for you tests to run shouldn’t feel like watching water boil. Scenarios are run concurrently for maximum speed - run hundreds of API requests and test assertions in seconds.
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Prism Introduction](../prism/overview.md)
|
||||
* [Leveraging Open API](levergage-openapi.md)
|
||||
* [Continuous Integration](continuous-integration.md)
|
||||
* [Run Scenarios In Stoplight](run-test-stoplight.md)
|
||||
@@ -1 +1,75 @@
|
||||
# Pass Data Between Steps
|
||||
|
||||
Most scenarios will involve more than one step, and oftentimes you will need to share data between steps.
|
||||
|
||||
For example, imagine a simple scenario that tests the CRUD operations on a "todos" model. It might involve 5 steps:
|
||||
|
||||
1. CREATE /todos
|
||||
2. GET /todos/{todoId}
|
||||
3. PUT /todos/{todoId}
|
||||
4. DELETE /todos/{todoId}
|
||||
5. GET /todos/{todoId} (to make sure 404 not found)
|
||||
|
||||
In order for this to work, steps 2-5 need to be able to access the `id` of the newly created todo in step 1. To do this, we'll save the new `id` property in step 1 to the $.ctx object.
|
||||
|
||||
### The $.ctx object
|
||||
|
||||
The $.ctx object makes it easy to store temporary data for use during the course of a single scenario run. By default, the $.ctx object will be empty at the start of every run. Use it to share data between steps.
|
||||
|
||||
### Using the $.ctx object
|
||||
|
||||
To use a ctx variable in your scenario, simply use the {$.ctx.variableName} syntax. For example, if your ctx variable is called `todoId`, and you want to use it in your step's URL, you would do something like this:
|
||||
|
||||
`/todos/{$.ctx.todoId}`
|
||||
|
||||
When the step is run, `{$.ctx.todoId}` will be replaced by whatever $.ctx.todoId has been set to in a previous step.
|
||||
|
||||
You can use variables anywhere in your step, including url, auth, headers, request body, assertions, captures, and scripting.
|
||||
|
||||
To use environments in a before script, after script, or step with type script:
|
||||
|
||||
```js
|
||||
// would print the postId
|
||||
console.log($.ctx.get('todoId');
|
||||
```
|
||||
|
||||
In the screenshot below, we are using a `todoId` ctx variable that is set in a previous step. It is helping us create the URL, and is also used in a test assertion to make sure that the API request responds with the exact id we are requesting.
|
||||
|
||||

|
||||
|
||||
### Setting ctx variables
|
||||
|
||||
#### With Captures
|
||||
|
||||
Save values from your step to your ctx object, for use in subsequent steps.
|
||||
|
||||
To accomplish this, open up the Captures tab of one of your steps and select $.ctx on the lefthand side of the assignment. In the image below we are saving the todoId property of the Create Todo response back to a variable on our ctx called `todoId`. We will use this variable in subsequent steps.
|
||||
|
||||

|
||||
|
||||
#### With Scripting
|
||||
|
||||
When you need more complicated conditional logic or processing, scripting is the way to go. Scripts are plain javascript, and give you access to the $.ctx object. You can achieve the same results as the capture screenshot above as seen in the screenshot below.
|
||||
|
||||

|
||||
|
||||
### When to use ctx variables
|
||||
|
||||
You can think of ctx variables as a temporary state in your scenario. In general, we recommend using them for values that are created during the course of a single scenario that need to be shared with subsequent steps. This includes things like ids, usernames, and randomly generated tokens.
|
||||
|
||||
<!-- theme: warning -->
|
||||
> We do **NOT** recommend using ctx variables for more permanent values that need to persist across scenario runs. For this persisted value use case, we recommend using the $$.env object, which is explained in detail [here](variables-environment.md).
|
||||
|
||||
### Debugging ctx variables
|
||||
|
||||
$.ctx variables can be manually set when running a step. This is useful if you are trying to debug a single step in the middle of a scenario that relies on a ctx value set in a previous step. Instead of running the entire scenario to generate the needed ctx value, you can set it in the UI manually. In the screenshot below, we can set the todoId ctx variable before running the step to debug what would happen with a particular todoId value.
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Variables Overview](variables-overview.md)
|
||||
* [Context Variables](variables-context.md)
|
||||
* [Variables Environment](variables-environment.md)
|
||||
|
||||
@@ -1 +1,70 @@
|
||||
# Running Scenarios
|
||||
|
||||
Scenarios allow you to quickly and efficiently test APIs. Scenarios can be
|
||||
run in a variety of different ways, including from the [command-line with
|
||||
Prism](./run-test-terminal.md) or by [URL](./run-test-url). However, the easiest
|
||||
way is through the Stoplight editor.
|
||||
|
||||
<!-- theme: info -->
|
||||
|
||||
> If you haven't created your first scenario yet, please [do so before
|
||||
> continuing](./scenarios-introduction.md)
|
||||
|
||||
Scenarios in Stoplight are composed of three different levels:
|
||||
|
||||
* **Steps**: low-level building blocks that compose a scenario.
|
||||
Steps allow you to easily chain individual actions (e.g., performing a
|
||||
web request) together, enabling for more complex testing workflows.
|
||||
|
||||
* **Scenarios**: a series of **steps** that perform a high-level
|
||||
action (e.g., registering a new user).
|
||||
|
||||
* **Collections**: a series of **scenarios** that encapsulate an
|
||||
entire test suite. Collections are the highest-level building blocks for creating
|
||||
a library of API interactions and tests.
|
||||
|
||||
Each level above can be run individually or all together.
|
||||
|
||||
## Running a Step
|
||||
|
||||
Once you have created a scenario **step**, use the **Run Step** button to
|
||||
execute that step. The **Run Step** button is available towards the top of the
|
||||
editor, as shown below.
|
||||
|
||||

|
||||
|
||||
## Running a Scenario
|
||||
|
||||
Once you have added enough steps to a **scenario**, use the **Run Scenario**
|
||||
button to execute that scenario. The **Run Scenario** button is available
|
||||
towards the top of the editor while viewing the scenario configuration/overview,
|
||||
as show below.
|
||||
|
||||

|
||||
|
||||
<!-- theme: info -->
|
||||
|
||||
> Scenarios can also be run directly from every step using the **Run Scenario**
|
||||
> button
|
||||
|
||||
## Running a Collection
|
||||
|
||||
Once you have added created enough scenarios to compose a **collection**, use
|
||||
the **Run Collection** button to run the entire collection (including all
|
||||
scenarios and steps). The **Run Collection** button is available towards the top
|
||||
of the editor while viewing the collection home screen, as shown below.
|
||||
|
||||

|
||||
|
||||
<!-- theme: info -->
|
||||
|
||||
> Collections can also be run from the scenario and step screens using the **Run
|
||||
> Collection** button
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Scenarios Overview](./scenarios-introduction.md)
|
||||
* [Running Scenarios from the Command-Line](./run-test-terminal.md)
|
||||
* [Running Scenarios by URL](./run-test-url.md)
|
||||
|
||||
@@ -1,80 +1,75 @@
|
||||
# Running a Scenario from Terminal
|
||||
# Running Prism from the Terminal
|
||||
|
||||
It is very easy to run scenario collections, or individual scenarios, on your own computer, completely outside of the Scenarios app.
|
||||
|
||||
First, install Prism, our command line tool for running scenarios.
|
||||
|
||||
*On macOs or Linux:*
|
||||
```
|
||||
_On macOS or Linux:_
|
||||
|
||||
```bash
|
||||
curl https://raw.githubusercontent.com/stoplightio/prism/2.x/install.sh | sh
|
||||
```
|
||||
|
||||
*On Windows:*
|
||||
<!-- theme: info -->
|
||||
|
||||
> When installed through the installation script, Prism will be installed to `/usr/local/bin/prism`
|
||||
|
||||
_On Windows:_
|
||||
|
||||
```
|
||||
Download from https://github.com/stoplightio/prism/tree/2.x
|
||||
```
|
||||
|
||||
After installing, you should be able to run `prism -h` (or `prism.exe -h` in Windows) and see some help text.
|
||||
After installing, you should be able to run `prism -h` (or `prism.exe -h` in Windows) from your CLI and see the Prism help text.
|
||||
|
||||
The Scenario app has a convenient display that gives you the exact command required to run the collection or scenario that you are viewing, taking into account your current environment variables. If you have the Scenario editor connected to a local file on your computer, it will use the path to that file, otherwise it will use the Scenario SRN (unique identifier).
|
||||
The Scenario app has a convenient display that gives you the exact command required to run the collection or scenario that you are viewing (taking into account your current environment variables). If you have the Scenario editor connected to a local file on your computer, it will use the path to that file, otherwise it will use the Scenario SRN (unique identifier).
|
||||
|
||||
<!-- theme: warning -->
|
||||
|
||||
> Keep in mind that if you are storing your Scenarios on Stoplight's servers, and running them from the command line, you must save them in the Stoplight app before running! This is because Prism will make a call to the Stoplight API to fetch your Scenario JSON, which it will then run from your computer.
|
||||
|
||||
See below for a screenshot of the "Run From Terminal" command generator. The command in this box will update live in response to environment, user, and scenario changes.
|
||||
|
||||

|
||||
<!-- FIXME: image showing "Run from Terminal" option under a scenario -->
|
||||
|
||||
## Running Local Files
|
||||
## Running Scenarios
|
||||
|
||||
The `prism conduct` command accepts a filepath. So, if you are working with [local scenario collection](#docTextSection:Ap4Z2B7RgbbLFLjJD) .json files, you can run them with something like:
|
||||
To run a local Scenario, you can use the `prism conduct` command. The `conduct`
|
||||
command accepts either a local file path or URL. If you are working with a local
|
||||
Scenario `collection.json` file, you can run the Scenario using the following
|
||||
command:
|
||||
|
||||
```bash
|
||||
# Run a local scenario
|
||||
prism conduct /path/to/collection.json
|
||||
|
||||
# Run a remote scenario by URL
|
||||
prism conduct "https://export.stoplight.io/1234/master/main.scenarios.yml"
|
||||
```
|
||||
|
||||
## Including Specs For Contract Testing
|
||||
For more information on Scenarios and how they can be used, see [here](./scenarios-introduction.md).
|
||||
|
||||
If you are using [contract testing](#docTextSection:tFWniZdshJYLLtKms), you will need to include the filepath to the API specification as part of the command. This is what that looks like:
|
||||
## Contract Testing
|
||||
|
||||
To use Prism for contract testing (or API validation), you can use the `prism validate` command.
|
||||
The `validate` command takes a `--spec` argument, which is either a file path or URL to an OpenAPI specification file.
|
||||
To run a contract test against the default API URL set in the specification, use the command:
|
||||
|
||||
```bash
|
||||
prism conduct myOrg/scenarios/myScenarios --spec /path/to/my/swagger.json
|
||||
prism validate --spec /path/to/my/spec.json
|
||||
```
|
||||
|
||||
## Continuous integration
|
||||
You can also run a contract test against a specific upstream URL with the
|
||||
`--upstream` argument.
|
||||
|
||||
Most CI products (Circle CI, Travis, Jenkins, Codship, etc) generally function in the same way: setup environment, invoke commands to run tests. With Scenarios + Prism, the process is similar. Install Prism, and then configure the CI process to run the appropriate Prism command. We've included instructions for Circle CI below, but these concepts should loosely apply to other CI products.
|
||||
|
||||
#### Circle CI
|
||||
|
||||
Integrating [Prism](http://stoplight.io/platform/prism) into Circle CI is easy. All you need to do is install Prism and overide the test command.
|
||||
|
||||
To install Prism just add a dependency to your circle config.
|
||||
|
||||
|
||||
``` yaml
|
||||
dependencies:
|
||||
pre:
|
||||
- curl https://raw.githubusercontent.com/stoplightio/prism/2.x/install.sh | sh
|
||||
```bash
|
||||
prism validate --spec /path/to/my/spec.json --upstream http://localhost:8080
|
||||
```
|
||||
|
||||
For more information on contract testing and how it can be used, see [here](./contract-testing.md).
|
||||
|
||||
Then override the default test command for circle in your config.
|
||||
## Related
|
||||
|
||||
|
||||
``` yaml
|
||||
test:
|
||||
override:
|
||||
- prism conduct orgId/scenarios/scenarioId
|
||||
```
|
||||
|
||||
When running `prism conduct` you can:
|
||||
|
||||
- Use the Scenario SRN, as displayed above.
|
||||
- Include the Scenario JSON on your CI server, and pass in its absolute file path
|
||||
- Pass in the absolute URL to the scenario JSON served up via HTTP.
|
||||
|
||||
<!-- theme: warning -->
|
||||
> Don't forget to pass in any required environment values with the --env command line flag (or you can provide the filepath to a json file with your environment variables)!
|
||||
|
||||
For convenience, you can find the full command to run your scenario collection or individual scenario in the Stoplight app.
|
||||
* [Scenarios Overview](./scenarios-introduction.md)
|
||||
* [Contract Testing Overview](./contract-testing.md)
|
||||
* [Integrating Prism into a CI Pipeline](./continuous-integration.md)
|
||||
|
||||
@@ -1 +1,120 @@
|
||||
# Triggering Scenarios by URL
|
||||
|
||||
In addition to being able to run tests [through Stoplight](./run-test-stoplight.md) and [the terminal](./run-test-terminal.md),
|
||||
scenarios can also be run by issuing a HTTP request.
|
||||
|
||||
To trigger a scenario by URL, there are two methods:
|
||||
|
||||
* Issuing a HTTP `GET` request, which runs the collection with the project's default
|
||||
settings and configuration.
|
||||
|
||||
* Issuing a HTTP `POST` request, which runs the collection with variables
|
||||
populated by the request's JSON body. This is necessary if you have passwords
|
||||
or other sensitive pieces of data that are not stored in Stoplight, but are
|
||||
required for running the scenario.
|
||||
|
||||
## Finding the Scenario URL
|
||||
|
||||
Every scenario has a unique URL that can be used to remotely trigger the
|
||||
scenario. To find this URL:
|
||||
|
||||
* Go to the scenario's summary in Stoplight
|
||||
|
||||
* Below the scenario summary is a "Trigger This Collection" section
|
||||
|
||||
* Within this section is a "Trigger by URL" containing the URL unique to this
|
||||
scenario
|
||||
|
||||

|
||||
|
||||
## Triggering Scenarios
|
||||
|
||||
If the scenario is part of a public project and does not require any
|
||||
customization to be run, then it can be triggered by issuing a simple HTTP `GET`
|
||||
request to the scenario's URL, as shown below.
|
||||
|
||||
```bash
|
||||
$ curl 'https://oihdflk5hiyltnnsxelttmnsw4ylsnfxxgltznvwa.prism.stoplight.io/'
|
||||
{
|
||||
"status": "completed",
|
||||
"failCount": 3,
|
||||
"passCount": 6,
|
||||
"time": 555.3748400000001,
|
||||
"env": {
|
||||
...
|
||||
```
|
||||
|
||||
To customize the scenario's variables (i.e., to add passwords and other sensitive
|
||||
information), they can either be included as URL query parameters in the `GET`
|
||||
request, or included within the request body of a `POST` request.
|
||||
|
||||
### Customizing Variables with Query String Parameters
|
||||
|
||||
You can customize the variables included in the scenario at runtime by adding
|
||||
extra [query string parameters](https://en.wikipedia.org/wiki/Query_string) to
|
||||
the URL.
|
||||
|
||||
For example, if you have an `api_token` variable that is required to run your
|
||||
scenario, it can be added to the scenario by attaching the `?api_token=abc123`
|
||||
query string to the URL (where `abc123` is the value of the `api_token`
|
||||
variable).
|
||||
|
||||
### Customizing Variables with a HTTP POST Body
|
||||
|
||||
In addition to adding a query string parameter, scenario variables can also be
|
||||
updated by using a HTTP `POST` request instead of a `GET` request. When using
|
||||
this method, the `POST` body must be composed of JSON with the JSON keys
|
||||
corresponding to the variables within the scenario.
|
||||
|
||||
Similar to the example above, if you have an `api_token` variable that is
|
||||
required to run your scenario, issuing a HTTP `POST` with the following JSON
|
||||
body will inject the variable into the scenario runtime.
|
||||
|
||||
```json
|
||||
{
|
||||
"api_token": "abc123"
|
||||
}
|
||||
```
|
||||
|
||||
To issue a `POST` request from the CLI, you can use the `curl` command. For
|
||||
example:
|
||||
|
||||
```bash
|
||||
$ curl -XPOST \
|
||||
--data-binary '{"api_token":"abc123"}' \
|
||||
'https://oihdflk5hiyltnnsxelttmnsw4ylsnfxxgltznvwa.prism.stoplight.io/'
|
||||
{
|
||||
"status": "completed",
|
||||
"failCount": 3,
|
||||
"passCount": 6,
|
||||
"time": 555.3748400000001,
|
||||
"env": {
|
||||
...
|
||||
```
|
||||
|
||||
### Triggering Scenarios in Private Projects
|
||||
|
||||
Public project scenarios can be triggered directly through the scenario URL with
|
||||
no further action needed. Private projects, however, must have an API token
|
||||
specified so that the request can be authenticated properly. To generate a new
|
||||
API token for your Stoplight acccount, see
|
||||
[here](https://next.stoplight.io/profile/access-tokens).
|
||||
|
||||
Once you have an API token, set it under the `Private-Token` header in order for
|
||||
it to be used to authenticate with the Stoplight API. For example:
|
||||
|
||||
```bash
|
||||
$ curl -H 'Private-Token: H4BTDASDf5sGHMWJSfE32' ...
|
||||
```
|
||||
|
||||
<!-- theme: warning -->
|
||||
|
||||
> Be sure to keep all private tokens safe! They can be used to authenticate
|
||||
> requests with any project that your account has access to.
|
||||
|
||||
---
|
||||
|
||||
**Related**
|
||||
|
||||
* [Running Scenarios through Stoplight](./run-test-stoplight.md)
|
||||
* [Running Scenarios from the Terminal](./run-test-terminal.md)
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
Stoplight Scenarios is a powerful (but accessible!) tool that takes the pain out of API testing. It is a standalone product, available on [the web](https://scenarios.stoplight.io), and as a [desktop app](https://download-next.stoplight.io).
|
||||
|
||||
We generally recommend the desktop app when possible. It works with local servers, behind firewalls, and exchanges information with tools on your computer like Git or your favorite IDE. You can switch seamlessly between the desktop app and the web app.
|
||||
|
||||
We engineered Scenarios from the ground up to be:
|
||||
|
||||
- **Powerful** Easily assert, capture, transform, and validate your API Spec (Swagger) against your actual API. And if that isn’t enough, Prism has a powerful javascript runtime.
|
||||
|
||||
- **Portable** Scenarios are described in plain JSON with a well thought out, robust specification. Use our visual editor to quickly generate and manage this JSON. They can be run from our visual tooling, or completely outside of Stoplight, on your own machines or on your continuous integration server.
|
||||
|
||||
- **Flexible** Your APIs, your tests, your way. Scenarios only test what you want them to. They have no opinion about your architecture (Monolithic vs Microservices), company structure (in house vs distributed), development lifecycle (production vs TDD), and your environment (development vs staging vs production).
|
||||
|
||||
- **Fast** Time can’t be slowed down, and we can’t give it back to you. Creating tests should be quick, and waiting for you tests to run shouldn’t feel like watching water boil. Scenarios are run concurrently for maximum speed - run hundreds of API requests and test assertions in seconds.
|
||||
|
||||
### Editor UI Overview
|
||||
|
||||

|
||||
BIN
assets/images/$.ctx.todoId-Assertion.png
Normal file
|
After Width: | Height: | Size: 219 KiB |
BIN
assets/images/$.ctx.todoId-Capture.png
Normal file
|
After Width: | Height: | Size: 202 KiB |
BIN
assets/images/$.ctx.todoId-Manual.png
Normal file
|
After Width: | Height: | Size: 157 KiB |
BIN
assets/images/$.ctx.todoId-Scripting.png
Normal file
|
After Width: | Height: | Size: 233 KiB |
BIN
assets/images/run-test-stoplight.png
Normal file
|
After Width: | Height: | Size: 30 KiB |
BIN
assets/images/run-test-stoplight2.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
BIN
assets/images/run-test-stoplight3.png
Normal file
|
After Width: | Height: | Size: 65 KiB |
BIN
assets/images/run-test-url.png
Normal file
|
After Width: | Height: | Size: 63 KiB |
BIN
assets/images/scenarios-editor-overview.png
Normal file
|
After Width: | Height: | Size: 443 KiB |
BIN
assets/images/viewing-changes.png
Normal file
|
After Width: | Height: | Size: 72 KiB |
BIN
assets/images/viewing-changes2.png
Normal file
|
After Width: | Height: | Size: 86 KiB |