Compare commits
4 Commits
taylor-pro
...
rowa97-pat
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
7a4eb99602 | ||
|
|
8f47aaee16 | ||
|
|
ae0d000f81 | ||
|
|
b029a36da5 |
43
articles/getting-started/writers-playbook.md
Normal file
43
articles/getting-started/writers-playbook.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# Technical Writer Playbook
|
||||
|
||||
Documenting an API is crucial to its success but can be extremely time consuming. Here at Stoplight, we believe documentation should be beautiful, clean, and robust while maintaining a streamlined turnaround time. We’ve created a holistic documentation tool, Hubs, to address some of the problems our users were facing including:
|
||||
|
||||
- Documenting Endpoints
|
||||
- Testing Endpoints
|
||||
- Creating Non-Reference Documentation
|
||||
- Managing Content
|
||||
- External and Internal Referencing
|
||||
- Design and Style
|
||||
|
||||
|
||||
## Documenting Endpoints
|
||||
The most key component to API Documentation are its endpoints. To that end, we created a reference builder that allows you to [“power pages”](/documentation/referencing-other-data-sources) with your specification as you see fit. When you power a page or subpage with your specification, the endpoints are automatically documented and styled for legibility and aesthetic design.
|
||||
|
||||
## Testing Endpoints
|
||||
Testing endpoints is a valuable tool for anyone who wants to consumer your API. Users want to know that your API functions properly before they commit to using it. To address this problem, we created [“Try it Out,” an HTTP Request Maker](/modeling/modeling-with-openapi/sending-http-requests). Try it Out allows you to send HTTP Requests to your API to test out its endpoints under any number of different conditions. You can customize Try it Out with security schemes, variables, headers, queries, and it even generates code in various programming languages.
|
||||
|
||||
## Creating Non-Reference Documentation
|
||||
Great documentation is more than just API endpoints. Guides, tutorials, and other supplemental information enhance your users experience by providing them with all the information they need to access your API and your product. We broadened Hubs scope to accomodate all product documentation needs. You can easily build out your content within [Blocks](/documentation/blocks), a number of flexible content structures that can house a number of different forms of content including markdown, images, code snippets, and much more.
|
||||
|
||||
## Managing Content
|
||||
Organizing a complex APIs endpoints and supplemental information can be a challenging task. Some specification can have hundreds of endpoints with supplemental information throughout. To assist with organizing content, we created an overview of all your pages, subpages, and their connections called “Table of Contents”. With a bird’s eye view of your content, you can easily organize and manage your content through drag drop functionality.
|
||||
|
||||
## External and Internal Referencing
|
||||
To accomodate a larger variety of writing workflows, we expanded the capabilities of [Powering a Page](/documentation/referencing-other-data-sources) to allow for more files internally and externally to be referenced. You can now easily reference specification, Markdown, YAML, JSON, and Scenario files from within a Project or externally located.
|
||||
|
||||
## Design and Style
|
||||
We wanted to create a new, beautiful, minimalistic, efficient design for less design-oriented individuals while allowing for customization. Hubs was designed to be display your documentation in a neat, efficient structure designed specifically for displaying the real beauty, your API. On the other hand, we didn’t want to stifle the creativity that goes into documentation design so we added in [theming](/documentation/design/theming) and [custom CSS](/documentation/design/custom-css). We also made it easier to add navigation, different kinds of content, and a more robust search.
|
||||
|
||||
---
|
||||
Related Links
|
||||
- [Documentation with Hubs](/documentation/introduction)
|
||||
- [Routing](/documentation/getting-started/routing)
|
||||
- [Headers](/documentation/getting-started/header-footer)
|
||||
- [Pages](/documentation/getting-started/pages)
|
||||
- [Subpages](/documentation/getting-started/subpages)
|
||||
- [Blocks](/documentation/blocks)
|
||||
- [Referencing Other Data Sources](/documentation/referencing-other-data-sources)
|
||||
- [Publishing](/documentation/publishing)
|
||||
- [Theming](/documentation/design/theming)
|
||||
- [Custom CSS](/documentation/design/custom-css)
|
||||
|
||||
@@ -1,61 +0,0 @@
|
||||
# Git Repositories
|
||||
|
||||
## What
|
||||
The Stoplight Platform is built on top of Git. This means that all your projects are Git repositories and that our platform benefits from all the additonal functionality provided by Git. To access the Git funtionality, you will need to clone your Git repository by generating an Access Token.
|
||||
|
||||
> You can also use Access Tokens to access the Stoplight API, authenticate Prism in a continuous integration enviornment, and access the underlying Git repositories for projects. You can make this part of your Git workflow, add it to scripts, or your CI/CD process
|
||||
|
||||
## Who
|
||||
|
||||
If you have write access to a project, you will be able to:
|
||||
* Pull projects via Git
|
||||
* Commit to projects via Git
|
||||
* Push changes to projects via Git
|
||||
|
||||
If you have read access to a project, you will be able to:
|
||||
* Pull your project via Git
|
||||
|
||||
## How to Clone Your Stoplight Git Repository
|
||||
|
||||
1. Select the **Settings** tab on the platform homepage
|
||||
2. Select **Access Tokens** from the left
|
||||
|
||||

|
||||
|
||||
3. Create a token to access projects that your Stoplight account has proper permissions for (These permissions match the ones in the Stoplight UI)
|
||||
|
||||
> You can name your token whatever you want. Once you have created the token, copy it, and only store it in a safe location. Once you close the window, you will not see it again
|
||||
|
||||
3. On your machine, store your access token as an environmental variable (recommended)
|
||||
|
||||
For example, on Mac/Linux:
|
||||
|
||||
```
|
||||
export STOPLIGHT_TOKEN="1234567890"
|
||||
```
|
||||
|
||||
4. You can then `git clone` the repo, replace `{stoplight-username}`, `{username}`, and `{project-name}` with the appropriate information:
|
||||
|
||||
```
|
||||
git clone https://{stoplight-username}:$STOPLIGHT_TOKEN@git.stoplight.io/{username}/{project-name}.git
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
git clone https://taylor:$STOPLIGHT_TOKEN@git.stoplight.io/taylor/test-new.git
|
||||
```
|
||||
|
||||
> If the project is associated with an organization and not a personal project, replace `username` with `organization-name`
|
||||
|
||||
5. Now you can make changes to your files, commit, and push to your master branch. You can see these changes in the Stoplight UI as well as the "History of Changes"
|
||||
|
||||
> Remember: You will only see changes on the master branch in the UI at this time.
|
||||
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [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)
|
||||
Reference in New Issue
Block a user