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。

参数仅仅是用来参数化对资源的访问。这尤其适用于帖子和搜索： /orders/find?q=blahblah&sort=foo。参数和子资源之间有一条细线： /orders/view/client/23/active versus /orders/view/client/23?show=active。我建议使用子资源样式并为搜索保留参数。

由于每个端点都表示一个状态转移（用于处理助记符），因此自定义标头仅应用于不涉及资源名称（URL），资源状态（主体）或参数的事物影响资源（参数）。剩下有关自定义标头请求的真实元数据。

HTTP有很多标题供您选择，这些标题涵盖了您所需的大多数内容。我看到自定义标头出现在代表用户操作的系统到系统请求中。代理系统将验证用户并将“ X-User: userid” 添加到标题中，并使用系统凭据来命中端点。接收系统会验证系统凭据已被授权代表用户执行操作，然后确认用户已被授权执行该操作。

自定义标题具有以下优点：

• 可以通过网络工具/脚本（身份验证，元信息等）轻松读取
• 使网址不受安全性的影响（更安全，不在浏览器/代理缓存中）
• 保持网址更整洁：允许更好地缓存资源

只有在没有其他方法可以按标准或约定传递信息时，我才使用自定义标头。Darren102正在解释传递该值的典型方法。通过使用使用自定义标头的典型模式与Api，您的Api将会更加友好，这并不是说您将没有使用它们的情况，只是它们应该是最后的手段，而HTTP规范尚未处理过这些。

何时在REST API的请求部分中使用... HTTP标头？

身份验证：GUID，基本身份验证，自定义令牌等，例如， 带有REST api的Guid令牌（而不是用户名/密码）的基本身份验证

如果您参与在PCI-DSS或其他安全规则所覆盖的域之间传递令牌或其他类似身份验证的信息，则您可能还必须埋入参数，因为某些法规明确要求身份验证元素不包含可能被重播的URL（来自浏览器历史记录，代理日志等）。

REST没有标准，但是可以接受的方式是

GET /orders/view/23

不使用自定义标头，因此23 after视图假定为id，因此您将拥有一个接受id的函数，因此仅产生该信息。

我不会使用自定义标头，因为您不知道是否有任何代理会传递这些标头。基于URL的方法。

GET / orders / view / client / 23

绝对可以：

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

考虑到封装不是一个好习惯，您可以使用自定义标头来包含有关部分处理的请求的更多信息。标头是安全的。