什么是检查客户端是否可以访问资源的RESTful方式？(What's the RESTful

我试图确定一个REST API的最佳实践来确定客户是否可以访问特定资源。 两个简单的例子场景：

一个电话目录查询服务。 客户端查找通过访问如电话号码。
GET http://host/directoryEntries/numbers/12345
...其中12345的电话号码，试图找到在目录中。 如果它存在，它会返回又像电话号码，它是人的姓名和地址信息。

一种视频格式换档服务。 客户端提交的视频在一个格式如。
POST http://host/videos/
...并接收“视频GUID”已经由服务器进行视频生成。 客户端然后检查如。
GET http://host/videos/[GUID]/flv
......以获得视频，转换成FLV格式，如果转换后的版本存在。

你会发现，在这两种情况下上述，我没有提到，如果被检查的资源， 不存在会发生什么。 这是我在这里的问题。 我在阅读各种 其他 地方 ，对客户机的正确RESTful方式检查资源是否存在这里是调用HEAD （或者GET上的资源），如果资源不存在，它应该期待一个404响应。 这将是很好，所不同的是404响应被广泛认为是一种“错误”; 在HTTP / 1.1规范规定，在4XX类的状态码适用于案件中，客户端“似乎出现了偏差”。 可是等等; 在这些例子中，客户端肯定没有错误。 该公司预计 ，它可以拿回404（或其他人;也许是403，如果它无权访问该资源），并已在请求资源没有错任何责任。 404并非意在表明一个“错误状态”，它仅仅是信息 - “这不存在”。

和浏览器的行为，如HTTP规范建议，因为如果404响应是一个真正的错误。 谷歌浏览器和Firebug的控制台喷涌出一个大大的红“404 Not Found”错误信息到的Javascript控制台404由XHR请求中接收，无论它是由错误处理程序处理或不每一次，并没有方法来禁用它。 这不是用户的一个问题，因为他们看不到控制台，但作为一个开发者，我不想看到一堆的404（或403等）的错误在我的JS控制台时，我完全知道好，他们都没有错误，但信息是由我的Javascript代码来处理。 它的线路噪音。 在我给了第二个例子，它的线路噪声到了极点，因为客户端很可能是轮询服务器/flv ，因为它可能需要一段时间来编译和客户端要显示“未编译尚未”，直到它得到非404。 有可能出现在JS控制台每隔一两秒钟一个404错误。

所以，这是我们与REST来检查资源的存在，最好的或最合适的方法是什么？ 我们如何避开在JS控制台线噪声？ 它很可能是提议，在我的第二个例子，不同的URI，可以查询到检查编译的状态 ，如：
GET http://host/videos/[GUID]/compileStatus
......然而，这似乎违反了REST原则一点点，给我; 你不使用HTTP来全面和注重的HTTP标头，而是创建自己的协议，让你在身体返回信息告诉你，你想，而不是知道什么，始终返回一个HTTP 200关闭浏览器了。 这是SOAP的一个主要批评 - 它试图“绕开” HTTP而不是用它来充分。 通过这个原理，为什么人会需要返回404个状态码？ 你总是可以返回一个200 -当然，200指出该资源的可用的状态信息 ，状态信息，告诉你什么你真的想知道-资源没有被发现。 当然RESTful方式应该是返回404个状态码。

如果我们把它应用到第一的我上面的例子这种机制似乎更加做作; 客户可能会查询：
GET http://host/directoryEntries/numberStatuses/12345
......当然收到200; 数12345的状态信息存在，并告诉你......该号码未在目录中找到。 这意味着，查询的任何号码是“200 OK”，即使它可能不存在 - 这似乎是一个不错的REST接口？

我缺少的东西吗？ 有没有更好的办法来确定资源是否存在REST风格，还是应该HTTP也许被更新，以表明不一定被认为是“错误”，非2xx状态码，并且只是信息？ 如果浏览器能够被配置为使得它们并不总是输出非2xx状态响应作为JS控制台“错误”？

PS。 如果你读了这一步，谢谢。 ;-)

Answer 1:

I think you have changed the semantics of the request. With a RESTful architecture, you are requesting a resource. Therefore requesting a resource that does not exist or not found is considered an error.

I use:

• 404 if GET http://host/directoryEntries/numbers/12345 does not exist.

• 400 is actually a bad request 400 Bad Request

Perhaps, in your case you could think about searching instead. Searches are done with query parameters on a collection of resources

What you want is GET http://host/directoryEntries/numbers?id=1234 Which would return 200 and an empty list if none exist or a list of matches.

Answer 2:

这是完全没使用404，表明资源没有找到。 从书“REST Web服务”（很不错的书关于REST的方式）一些报价：

404表示该服务器不能将客户端的URI映射到一个资源。 [...]一个web服务可以使用404响应作为信号到客户端，所述URI是“自由”; 那么客户端可以通过发送一个PUT请求到URI创建新的资源。 请记住，404可能是一个谎言掩盖一个403或401这可能是资源的存在，但服务器不希望让客户知道这一点。

使用404服务时无法找到请求的资源，不要过度使用，表示这实际上是不相关的资源是否存在错误。 此外，客户可以“查询”的服务知道这个URI是否自由与否。

执行长时间运行的操作类似的视频文件编码

HTTP具有同步请求 - 响应模型。 客户端打开因特网套接字服务器，使得其请求，并保持套接字打开，直到服务器发送的响应。 [...]

这个问题是不是所有的操作都可以在我们预期的HTTP请求采取的时间内完成。 某些操作需要数小时或数天。 HTTP请求必将那种不活动后超时。 即使没有，谁愿意保持开放的只是等待服务器响应天插座？ 难道就没有办法通过异步HTTP暴露这样的操作？

有，但它要求操作被分成两个或更多的同步请求。 第一个请求派生的操作，并且后续请求让客户了解操作的状态。 秘诀是状态码202（“接受”）。

所以，你可以做POST /videos创建的视频编码任务。 该服务将接受任务后，用202回答和提供的链接描述的任务状态的资源。

202 Accepted
Location: http://tasks.example.com/video/task45543

客户端可以查询这个URI看到任务的状态。 一旦任务完成，资源的表现将变得可用。

Answer 3:

IMO客户端已在请求一个不存在的资源确实是错误的。 在这两个例子您的服务可以以不同的方式，从而可避免在客户端的错误进行设计。 例如，在视频转换服务为GUID已经被分配，所述消息体在视频/ ID可包含一个标志，指示所述转换是否已完成与否。

同样，在电话簿例子，你正在寻找一个资源，这可以通过类似/数字处理/？search_number = 12345等，使服务器返回一个你可以再进一步查询匹配的资源列表。

浏览器是专为与HTTP规范工作，并显示错误是一个真正的响应（漂亮也有帮助）。 然而，你需要考虑你的JavaScript代码从浏览器中一个独立的实体。 所以，你有你的Javascript REST客户端，它知道服务是什么样的，并且是那种说不出话来问候你的服务的浏览器。

此外，REST是独立于理论的协议。 HTTP恰好是最常用的协议，在使用REST。 我能想到的另一个例子是Android的内容提供商，其设计是基于REST的，但不依赖于HTTP。

Answer 4:

我只看过GET / HEAD请求返回404（未找到）当资源不存在。 我认为，如果你想只得到一个资源的状态HEAD请求将被罚款，因为它不应该返回一个资源的主体。 这样你可以在这里你试图获取资源，你试图检查其所有脑干请求，并请求进行区分。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

编辑：我记得通过将报头到指定的服务器应该如何处理404错误的原始请求阅读的替代解决方案。 随着200回应线的东西，而是一个空体。

文章来源: What's the RESTful way to check whether the client can access a resource?