* .local服务URL是否RESTful？

Question

URL应该定位（而不是简单地标识）资源;一个必然结果是相同的URL必须引用相同的资源。但是，对于http://api.local/orders/333之类的网址，此规则似乎会被违反，其中api.local无法解析为每个人的主机，并且在以下情况下甚至可能无法解析为同一主机它确实解决了。 （例如，您可以在开发环境中的一个主机上指向api.local，在实时环境中指向另一个主机。）

1. 严格来说，主机名如api.local（或127.0.0.1）的网址是否为RESTful？
2. 这种方法可能会导致任何问题吗？
3. 有什么好的选择吗？ （哪个更好：http://flickr/或http://flickr.local/或http://flickr.api？）

Answer 1

URL通过指定该资源的路径以及用于访问该资源的协议来查找资源。您的所有示例都是RESTful。它们标识REST客户端要访问的与REST客户端相关的资源。

REST客户端可以自由指定他想要访问的资源的位置。 REST客户端应该知道api.local服务器包含或不包含他想要访问的资源。

如果您的REST服务器打算拥有一个普遍可访问的资源，那么您应该使用未找到的资源进行响应，除非它要求提供正确的URL。

您可能完全可以接受本地计算机上的REST服务器和Internet上的另一台服务器。 REST客户端将指定他想要访问的任何一个。

据说，有很多不同的URL引用相同的资源并不是最好的设计。因此使用api.local没有任何问题，但是当api.local和api引用不同的资源时，最好允许这样的事情。

Answer 2

网址代表“统一资源定位器”，而非“通用资源定位器”。 URL中没有暗示它应该是“全局”或“普遍”可访问的。所以我没有看到* .local用于本地测试的问题（对于我来说，从任何地方可以访问的测试或开发环境对我来说肯定是不好的。）

Answer 3

“只有一个URL应该返回资源”背后的主要实际问题之一是因为对缓存的影响。 如果您有两个相同资源的URL，则最终可以在缓存中使用两个副本。如果对其中一个执行PUT，则缓存应该使两者无效，但它不知道两个副本之间的关系。

关于使用可能解析为不同字节流的主机名的问题，具体取决于您取消引用它的位置，我根本不认为这是一个问题。从概念上讲，您正在访问相同的资源，它实际上只是该资源的不同实例。我将其广泛用作发现机制的一种形式。我开发了一个托管在服务器上的企业应用程序，我将其命名为“TMServer”。在组织内，只有一个TMServer实例，并且从该主机访问所有资源。例如http://TMServer/Suppliers在我的其他客户之一，相同的网址会解析为完全不同的供应商集合，但它在概念上仍然是“供应商列表”。

如果我的某个客户尝试与其他公司共享网址，则需要将该网址扩展为http://TMServer.company.com/Suppliers。然后，这将成为一个普遍唯一的URI。

通过使用DNS别名，我可以轻松地使用我的.hosts文件重定向TMServer指向的位置进行测试，并通过在DNS服务器中添加条目，我可以向网络上的所有用户广播该服务的可用性。 / p>

Answer 4

网址不是RESTful。应用程序是RESTful（或不是），但URL不是。实际上，在RESTful应用程序中，URL完全不相关，因此，您担心URL是否为RESTful这一事实表明您的应用程序不是。但这与URL没有任何关系。