URL表示资源本身。 客户是可以采取行动的资源，因此应该是基本网址的一部分： / orders / view / client / 23 。

The URL indicates the resource itself. A "client" is a resource that can be acted upon, so should be part of the base url: /orders/view/client/23.

参数只是参数化对资源的访问。这特别适用于帖子和搜索： / orders / find？q = blahblah& sort = foo 。参数和子资源之间有一条细线： / orders / view / client / 23 / active与/ orders / view / client / 23？show = active 。我推荐用于搜索的子资源样式和保留参数。

Parameters are just that, to parameterize access to the resource. This especially comes into play with posts and searches: /orders/find?q=blahblah&sort=foo. There's a fine line between parameters and sub-resources: /orders/view/client/23/active versus /orders/view/client/23?show=active. I recommend the sub-resource style and reserve parameters for searches.

由于每个端点都提供状态转移（以破坏助记符），因此自定义标头只应用于事物不涉及资源名称（url），资源状态（正文）或直接影响资源的参数（参数）。这留下了关于自定义标头请求的真实元数据。

Since each endpoint REpresents a State Transfer (to mangle the mnemonic), custom headers should only be used for things that don't involve the name of the resource (the url), the state of the resource (the body), or parameters directly affecting the resource (parameters). That leaves true metadata about the request for custom headers.

HTTP具有非常广泛的标题选择，涵盖了您需要的大部分内容。我看到自定义标题出现在系统到系统请求代表用户操作。代理系统将验证用户并向标头添加 X-User：userid 并使用系统凭据命中端点。接收系统验证系统凭据是否有权代表用户执行操作，然后验证用户是否有权执行操作。

HTTP has a very wide selection of headers that cover most everything you'll need. Where I've seen custom headers come up is in a system to system request operating on behalf of a user. The proxy system will validate the user and add "X-User: userid" to the headers and use the system credentials to hit the endpoint. The receiving system validates that the system credentials are authorized to act on behalf of the user, then validate that the user is authorized to perform the action.