|
| 1 | +# DocuSign Vendor specific Extensions |
| 2 | + |
| 3 | +The Swagger and OpenAPI specifications enable vendor specific extensions throughout Swagger files. |
| 4 | +The extensions must start with the letter x. All DocuSign extensions start with `x-ds-`. |
| 5 | + |
| 6 | +## Categories, Resources, Methods |
| 7 | +The OpenAPI specification does not focus on the idea of resources for APIs. |
| 8 | +In particular, the OpenAPI `tags` element can be used to add multiple tags to a method. |
| 9 | + |
| 10 | +DocuSign assigns each method to exactly one **resource**. Resources are usually plural nouns. |
| 11 | +They start with a capital letter. |
| 12 | + |
| 13 | +Methods are verbs. They are lower case. |
| 14 | + |
| 15 | +Resources are grouped together into "categories." Within the documentation, a three level table of contents is used: |
| 16 | +Categories, Resources, Methods. |
| 17 | + |
| 18 | +### Categories |
| 19 | +Categories are listed in the top level `x-ds-categories` element. It is an array of Category objects. |
| 20 | +Each object includes parameters: |
| 21 | + |
| 22 | +* `name` -- markdown format |
| 23 | +* `description` -- markdown format |
| 24 | +* `summary` -- markdown format |
| 25 | + |
| 26 | +### Resources |
| 27 | +Within the OpenAPI file, a method's resource name is stored in location `tags[0]` within the method's operation definition. |
| 28 | +Only one element of the `tags` array is used. |
| 29 | + |
| 30 | +The top level `tags` array holds the extended descriptions of the resources in markdown format. |
| 31 | + |
| 32 | +Each resource name exactly matchs a definition name. The resource (and definition) names start with a capital letter. |
| 33 | + |
| 34 | +The `description` field in the matching definition entry for the resource holds the resource's summary description, |
| 35 | +also in markdown format. |
| 36 | + |
| 37 | +Definitions that are also resources include the following extensions: |
| 38 | + |
| 39 | +* `x-ds-category` -- the name of the definition's (and resource's) owning category. |
| 40 | + The value will match a `name` value in the `x-ds-categories` array. |
| 41 | +* `x-ds-definition-name` -- the name of the definition as used for generating SDKs |
| 42 | +* `x-ds-order` -- an integer for ordering Resources with a Category table of contents entry. Not used. |
| 43 | +* `x-ms-summary` -- Not used. |
| 44 | + |
| 45 | +## Methods |
| 46 | +The heart of an API specification are the methods. |
| 47 | + |
| 48 | +A Method's Resource name is stored in `tags[0]` |
| 49 | + |
| 50 | +Important parameters for each method: |
| 51 | + |
| 52 | +* `description` -- markdown format. |
| 53 | +* `operationId` -- unique throughout the Swagger file. |
| 54 | +* `summary` -- markdown format. |
| 55 | +* `x-ds-in-sdk` -- is the method included in the SDK? Not used. |
| 56 | +* `x-ds-method` -- the method name within the resource's scope. This is the method name used in the API documentation. |
| 57 | +* `x-ds-methodname` -- the method name within the category's scope. This method name is used in the SDKs. |
| 58 | +* `x-ds-service` -- the owning category for the method. |
| 59 | + |
| 60 | +### Common method names |
| 61 | + |
| 62 | +Most resources include one or more common methods: |
| 63 | + |
| 64 | +| Method name | HTTP method | Description | |
| 65 | +| --- | --- | --- | |
| 66 | +| create | POST | creates a new resource instance | |
| 67 | +| get | GET | get a single instance of the resource | |
| 68 | +| list | GET | list current resources | |
| 69 | +| delete | DELETE | delete a resource | |
| 70 | +| update | PUT | update a resource | |
0 commit comments