REST API：自定义HTTP标头与URL参数
何时在REST API的请求部分中使用自定义HTTP头？
例：
你会用吗？
GET /orders/view (custom HTTP header) CLIENT_ID: 23 代替
GET /orders/view/client_id/23 or GET /orders/view/?client_id=23
该URL指示资源本身。 一个“客户”是一个可以采取行动的资源，所以应该成为基础URL的一部分： /orders/view/client/23 。
参数就是为了参数化对资源的访问。 这特别发挥post和search： /orders/find?q=blahblah&sort=foo 。 参数与子资源之间有一条细线： /orders/view/client/23/active versus /orders/view/client/23?show=active 。 我build议用于search的子资源样式和保留参数。
由于每个端点都提供了一个状态转移（用于修改助记符），因此自定义标题只能用于不涉及资源名称（URL），资源状态（主体）或参数的事物影响资源（参数）。 这留下了关于自定义标题的请求的真实元数据。
HTTP有一个非常广泛的标题select，涵盖了大部分你需要的东西。 在那里我看到自定义标题出现在系统中，代表用户操作的系统请求。 代理系统将validation用户，并向头添加“ X-User: userid ”，并使用系统凭证命中端点。 接收系统validation系统证书被授权代表用户行事，然后validation用户被授权执行该操作。
如果没有其他方式通过标准或惯例传递信息，我只会使用自定义标题。 Darren102正在解释通过这种价值的典型方式。 通过使用自定义标题，使用典型的模式诗将更加友好。但并不是说您不需要使用它们，只是应该是最后的手段，而且还没有被HTTP规范处理。
自定义标题具有以下优点：
- 可以通过networking工具/脚本轻松读取（身份validation，元信息…）
- 保持urls从安全的东西（更安全，而不是在浏览器/代理caching）
- 保持URL更清洁：允许更好地caching资源
我不会使用自定义标题，因为您不知道是否有代理会传递这些信息。 基于URL是要走的路。
GET / orders / view / client / 23
你什么时候在REST API的请求部分使用HTTP标头？
身份validation：GUID，基本身份validation，自定义令牌等，例如， 基于REST API的Guid令牌的基本身份validation，而不是用户名/密码
如果您涉及在PCI-DSS或其他安全规则所涵盖的域之间传递令牌或其他安全规则的类似其他authentication信息，则您可能还必须隐藏参数，因为某些法规明确要求身份validation元素不能使用可简单重播的URL浏览器历史logging，代理日志等）。
REST没有标准，但接受的方式是
GET /orders/view/23
不使用自定义标题，因此23后视图假设为id，因此，你将有一个函数，采取的ID，因此产生的信息。
绝对OK：
GET /orders/view/client_id/23 or GET /orders/view/?client_id=23
还行：
GET /orders/view/23 or
我会认为这也可以：
POST /orders/view (custom HTTP header) CLIENT_ID: 23
您可以使用自定义标头来包含有关部分处理的请求的更多信息，因为Enveloping不是一种好的做法。 标头是安全的 。
