Add markdown section

3 files changed, 188 insertions, 3 deletions

diff --git a/packages/sra-api/src/api.ts b/packages/sra-api/src/api.ts
index 33d4d3619..da61cb1b0 100644
--- a/packages/sra-api/src/api.ts
+++ b/packages/sra-api/src/api.ts
@@ -2,6 +2,7 @@ import { schemas } from '@0xproject/json-schemas';
 import { OpenApiSpec } from '@loopback/openapi-v3-types';
 
 import { examples } from './examples';
+import { md } from './md';
 import { generateParameters } from './parameters';
 import { generateResponses } from './responses';
 // We need to replace the `$ref`s to be openAPI compliant.
@@ -10,10 +11,9 @@ const openApiSchemas = JSON.parse(JSON.stringify(schemas).replace(/(\/\w+)/g, ma
 export const api: OpenApiSpec = {
     openapi: '3.0.0',
     info: {
-        version: '1.0.0',
+        version: '2.0.0',
         title: 'Standard Relayer REST API',
-        description:
-            '0x Protocol is an open standard. Because of this, we expect many independent applications to be built that will want to use the protocol. In order to make it easier for anyone to source liquidity that conforms to the 0x order format, relayers can opt-in to implementing a set of standard relayer API endpoints. In doing so, they allow clients of the standard relayer API to access the orders on their orderbook.',
+        description: md.introduction,
         license: {
             name: 'Apache 2.0',
             url: 'https://www.apache.org/licenses/LICENSE-2.0.html',
diff --git a/packages/sra-api/src/md/index.ts b/packages/sra-api/src/md/index.ts
new file mode 100644
index 000000000..076c3c45c
--- /dev/null
+++ b/packages/sra-api/src/md/index.ts
@@ -0,0 +1,5 @@
+import { readFileSync } from 'fs';
+
+export const md = {
+    introduction: readFileSync('src/md/introduction.md').toString(),
+};
diff --git a/packages/sra-api/src/md/introduction.md b/packages/sra-api/src/md/introduction.md
new file mode 100644
index 000000000..c3aa4d4da
--- /dev/null
+++ b/packages/sra-api/src/md/introduction.md
@@ -0,0 +1,180 @@
+# Pagination
+
+Requests that return potentially large collections should respond to the **?page** and **?per_page** parameters. For example:
+
+```
+curl https://api.example-relayer.com/v2/token_pairs?page=3&per_page=20
+```
+
+Page numbering should be 1-indexed, not 0-indexed. If a query provides an unreasonable (ie. too high) **per_page** value, the response can return a validation error as specified in the [errors section](#errors). If the query specifies a **page** that does not exist (ie. there are not enough **records**), the response should just return an empty **records** array.
+
+All endpoints that are paginated should return a **total**, **page**, **perPage** and a **records** value in the top level of the collection.  The value of **total** should be the total number of records for a given query, whereas **records** should be an array representing the response to the query for that page. **page** and **perPage**, are the same values that were specified in the request. See the note in [miscellaneous](#misc) about formatting `snake_case` vs. `lowerCamelCase`. 
+
+These requests include the [`asset_pairs`](#get-v2-asset-pairs), [`orders`](#get-v2-orders), and [`orderbook`](#get-v2-orderbook) endpoints.
+
+# Network Id
+All requests should be able to specify a **?networkId** query param for all supported networks. For example:
+```
+curl https://api.example-relayer.com/v2/token_pairs?networkId=1
+```
+If the query param is not provided, it should default to **1** (mainnet).
+
+Networks and their Ids:
+
+| Network Id | Network Name |
+| ---------- | ------------ |
+| 1          | Mainnet      |
+| 42         | Kovan        |
+| 3          | Ropsten      |
+| 4          | Rinkeby      |
+
+ If a certain network is not supported, the response should **400**  as specified in the [error response](#error-response) section. For example:
+ 
+```
+{
+    "code": 100,
+    "reason": "Validation failed",
+    "validationErrors": [
+        {
+            "field": "networkId",
+            "code": 1006,
+            "reason": "Network id 42 is not supported",
+        }
+    ]
+}
+```
+
+# Link Header
+
+A [Link Header](https://tools.ietf.org/html/rfc5988) can be included in a response to provide clients with more context about paging
+For example:
+
+```
+Link: <https://api.example-relayer.com/v2/token_pairs?page=3&per_page=20>; rel="next",
+<https://api.github.com/user/repos?page=10&per_page=20>; rel="last"
+```
+
+This `Link` response header contains one or more Hypermedia link relations.
+
+The possible `rel` values are:
+
+| Name  | Description                                                   |
+| ----- | ------------------------------------------------------------- |
+| next  | The link relation for the immediate next page of results.     |
+| last  | The link relation for the last page of results.               |
+| first | The link relation for the first page of results.              |
+| prev  | The link relation for the immediate previous page of results. |
+
+# Rate Limits
+
+Rate limit guidance for clients can be optionally returned in the response headers:
+
+| Header Name           | Description                                                                  |
+| --------------------- | ---------------------------------------------------------------------------- |
+| X-RateLimit-Limit     | The maximum number of requests you're permitted to make per hour.            |
+| X-RateLimit-Remaining | The number of requests remaining in the current rate limit window.           |
+| X-RateLimit-Reset     | The time at which the current rate limit window resets in UTC epoch seconds. |
+
+For example:
+
+```
+curl -i https://api.example-relayer.com/v2/token_pairs
+HTTP/1.1 200 OK
+Date: Mon, 20 Oct 2017 12:30:06 GMT
+Status: 200 OK
+X-RateLimit-Limit: 60
+X-RateLimit-Remaining: 56
+X-RateLimit-Reset: 1372700873
+```
+When a rate limit is exceeded, a status of **429 Too Many Requests** should be returned.
+
+# Errors
+
+Unless the spec defines otherwise, errors to bad requests should respond with HTTP 4xx or status codes.
+
+## Common error codes
+
+| Code | Reason                                  |
+| ---- | --------------------------------------- |
+| 400  | Bad Request – Invalid request format    |
+| 404  | Not found                               |
+| 429  | Too many requests - Rate limit exceeded |
+| 500  | Internal Server Error                   |
+| 501  | Not Implemented                         |
+
+## Error reporting format
+For all **400** responses, see the [error response schema](https://github.com/0xProject/0x-monorepo/blob/development/packages/json-schemas/schemas/relayer_api_error_response_schema.ts#L1).
+
+```
+{
+    "code": 101,
+    "reason": "Validation failed",
+    "validationErrors": [
+        {
+            "field": "maker",
+            "code": 1002,
+            "reason": "Invalid address"
+        }
+    ]
+}
+```
+
+General error codes:
+
+```
+100 - Validation Failed
+101 - Malformed JSON
+102 - Order submission disabled
+103 - Throttled
+```
+
+Validation error codes:
+
+```
+1000 - Required field
+1001 - Incorrect format
+1002 - Invalid address
+1003 - Address not supported
+1004 - Value out of range
+1005 - Invalid signature or hash
+1006 - Unsupported option
+```
+
+# Asset Data Encoding
+
+As we now support multiple [token transfer proxies](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#assetproxy), the identifier of which proxy to use for the token transfer must be encoded, along with the token information. Each proxy in 0x v2 has a unique identifier. If you're using 0x.js there will be helper methods for this [encoding](https://0xproject.com/docs/0x.js#zeroEx-encodeERC20AssetData) and [decoding](https://0xproject.com/docs/0x.js#zeroEx-decodeAssetProxyId). 
+
+The identifier for the Proxy uses a similar scheme to [ABI function selectors](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#function-selector).
+```
+// ERC20 Proxy ID  0xf47261b0
+bytes4(keccak256("ERC20Token(address)"))
+// ERC721 Proxy ID 0x08e937fa
+bytes4(keccak256("ERC721Token(address,uint256)"))
+```
+
+Asset data is encoded using [ABI encoding](https://solidity.readthedocs.io/en/develop/abi-spec.html). 
+
+For example, encoding the ERC20 token contract (address:  0x1dc4c1cefef38a777b15aa20260a54e584b16c48) using the ERC20 Transfer Proxy (id: 0xf47261b0) would be:
+```
+0xf47261b00000000000000000000000001dc4c1cefef38a777b15aa20260a54e584b16c48
+```
+
+Encoding the ERC721 token contract (address: `0x371b13d97f4bf77d724e78c16b7dc74099f40e84`), token id (id: `99`, which hex encoded is `0x63`) and the ERC721 Transfer Proxy (id: 0x08e937fa) would be:
+```
+0x08e937fa000000000000000000000000371b13d97f4bf77d724e78c16b7dc74099f40e840000000000000000000000000000000000000000000000000000000000000063
+```
+
+For more information see [the Asset Proxy](https://github.com/0xProject/0x-protocol-specification/blob/master/v2/v2-specification.md#erc20proxy) section of the v2 spec and the [Ethereum ABI Spec](https://solidity.readthedocs.io/en/develop/abi-spec.html).
+
+# Meta Data in Order Responses
+
+In v2 of the standard relayer API we added the `metaData` field. It is meant to provide a standard place for relayers to put optional, custom or non-standard fields that may of interest to the consumer of the API.
+
+A good example of such a field is `remainingTakerAssetAmount`, which is a convenience field that communicates how much of a 0x order is potentially left to be filled. Unlike the other fields in a 0x order, it is not guaranteed to be correct as it is derived from whatever mechanism the implementer (ie. the relayer) is using. While convenient for prototyping and low stakes situations, we recommend validating the value of the field by checking the state of the blockchain yourself, such as by using [Order Watcher](https://0xproject.com/wiki#0x-OrderWatcher).
+
+# Misc.
+
+*   All requests and responses should be of **application/json** content type
+*   All token amounts are sent in amounts of the smallest level of precision (base units). (e.g if a token has 18 decimal places, selling 1 token would show up as selling `'1000000000000000000'` units by this API).
+*   All addresses are sent as lower-case (non-checksummed) Ethereum addresses with the `0x` prefix.
+*   All URL query parameters are to be written in `snake_case` and all queries and responses specified in JSON should use `lowerCamelCase`.