## 請求（Requests）
### 在請求的body體使用JSON格式數據
在?`PUT`/`PATCH`/`POST`?請求的正文（request bodies）中使用JSON格式數據，而不是使用 form 表單形式的數據。這與我們使用JSON格式返回請求相對應，例如:
~~~
$ curl -X POST https://service.com/apps \
-H "Content-Type: application/json" \
-d '{"name": "demoapp"}'
{
"id": "01234567-89ab-cdef-0123-456789abcdef",
"name": "demoapp",
"owner": {
"email": "username@example.com",
"id": "01234567-89ab-cdef-0123-456789abcdef"
},
...
}
~~~
### 使用統一的資源路徑格式
#### 資源名（Resource names）
使用復數形式為資源命名，除非這個資源在系統中是單例的 (例如，在大多數系統中，給定的用戶帳戶只有一個)。 這種方式保持了特定資源的統一性。
#### 行為（Actions）
好的末尾不需要為資源指定特殊的行為，但在特殊情況下，為某些資源指定行為卻是必要的。為了描述清楚，在行為前加上一個標準的`actions`：
~~~
/resources/:resource/actions/:action
~~~
例如：
~~~
/runs/{run_id}/actions/stop
~~~
### 路徑和屬性要小寫
為了和域名命名規則保持一致，使用小寫字母并用`-`分割路徑名字，例如：
~~~
service-api.com/users
service-api.com/app-setups
~~~
屬性也使用小寫字母，但是屬性名要用下劃線`_`分割，以便在Javascript中省略引號。 例如：
~~~
service_class: "first"
~~~
### 支持方便的無id間接引用
在某些情況下，讓用戶提供ID去定位資源是不方便的。例如，一個用戶想取得他在Heroku平臺app信息，但是這個app的唯一標識是UUID。這種情況下，你應該支持接口通過名字和ID都能訪問，例如:
~~~
$ curl https://service.com/apps/{app_id_or_name}
$ curl https://service.com/apps/97addcf0-c182
$ curl https://service.com/apps/www-prod
~~~
不要只接受使用名字而放棄了使用id。
### 最小化路徑嵌套
在一些有父路徑/子路徑嵌套關系的資源數據模塊中，路徑可能有非常深的嵌套關系，例如:
~~~
/orgs/{org_id}/apps/{app_id}/dynos/{dyno_id}
~~~
推薦在根(root)路徑下指定資源來限制路徑的嵌套深度。使用嵌套指定范圍的資源。在上述例子中，dyno屬于app，app屬于org可以表示為：
~~~
/orgs/{org_id}
/orgs/{org_id}/apps
/apps/{app_id}
/apps/{app_id}/dynos
/dynos/{dyno_id}
~~~
