2012-02-06 81 views

回答

78

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”添加到标头并使用系统凭证来命中端点。接收系统验证系统凭证是否有权代表用户采取行动,然后验证用户是否有权执行该操作。

+0

感谢您的全面回答!你仍然会使用X-User作为一个移动API,其中有一个邪恶的代理(剥离标题)的风险仍然很高? – 2012-02-14 07:50:46

+1

不,我提到的X用户的用法是系统代表第三方的系统连接。例如,用户U与服务器A通话。服务器A向服务器B提供证书,并带有X用户头,表示“使用我的凭证检查我是否有权代表用户U执行此操作”。这出现在面向服务的体系结构中,通常你使用的是HTTPS。移动平台应该几乎总是用户自己的行为,并为交易使用适当的第一人称凭证。 – Nialscorva 2012-02-15 00:08:37

+4

第三段是我读过的最翔实的答案之一;-) – Alistair77 2013-05-31 11:36:24

2

没有为REST没有标准,但接受的办法是

GET /orders/view/23 

不使用设g自定义标题,因此23视图之后假定为id,因此您将有一个函数,它接受id并因此生成该信息。

3

我不会使用自定义标题,因为您不知道是否有代理会传递这些标题。基于URL的路是要走的路。

GET /命令/视图/客户/ 23

+1

我不会推荐自定义标题,但破碎的代理不是原因。代理被破坏,应该被修复。 – 2012-02-07 08:59:20

1

绝对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 
+0

REST-ful POST响应应该是一个位置标题设置为类似“/ orders/view/23”的HTTP 303。 – 2015-07-18 22:47:17

5

我只会在没有其他方式按标准或惯例传递信息时使用自定义标题。 Darren102正在解释传递价值的典型方式。通过使用自定义标题来使用典型的模式,你的Api将变得更加友好。并不是说你不会有使用它们的情况,只是它们应该是最后的手段,而且还没有被HTTP规范处理过。

+0

全心全意同意......如果有标准的方式来完成任务,永远不要重新发明轮子。 – 2012-02-07 00:02:14

3

什么时候在REST API的请求部分使用HTTP标头?

验证:GUID的,基本的身份验证,自定义标记,等如 Basic Authentication with a Guid token for REST api instead of username/password

如果你涉足令牌传递或其他认证类信息通过PCI-DSS或其它安全规则覆盖域之间您可能还必须隐藏参数,因为有些法规明确要求身份验证元素保留在可以轻松重播的URL之外(从浏览器历史记录,代理日志等)。

4

自定义页眉具有以下优点:

  • 很容易被网络工具来读/脚本(认证,元信息,...)
  • 保持免费网址,安全的东西(更安全,而不是在浏览器/代理缓存)
  • 保持清洁的网址:考虑到资源的更好的缓存
+0

他们也可以通过代理无提示/过滤 – fusi 2016-01-07 09:58:43

0

您可以使用自定义页眉包括有关部分处理的请求利弊的更多信息认为Enveloping不是一个好的做法。标题是secure