*。本地服务URL是否为RESTful？
一个URL据称可以找到（而不是简单地标识）一个资源;推论是相同的URL必须引用相同的资源。但是，对于像http://api.local/orders/333这样的URL，其中api.local无法解析为所有人的主机，并且在解决问题时甚至可能无法解析到相同主机，因此该规则似乎被违反。 （例如，你可能会在开发环境中的一个主机，而另一个环境中生活点api.local）*。本地服务URL是否为RESTful？
- 严格地说，是与像
api.local（或127.0.0.1）REST风格的主机名的网址？ - 这种方法可能会导致任何问题吗？
- 有没有什么好的选择？ （哪个更好？
http://flickr/或http://flickr.local/或http://flickr.api）
URL不是RESTful。应用程序是RESTful（或不），但URL不是。事实上，在一个RESTful应用程序中，URL是完全不相关的，所以仅仅是担心你的URL是否是RESTful就表明你的应用程序不是。但是这与网址没有任何关系。
的URL通过指定资源和协议的路径用来访问该资源所在的资源。你所有的例子都是RESTful。它们标识与REST客户机想要访问的REST客户机相关的资源。
REST客户端可以*指定他想访问的资源位置。 REST客户端应该知道api.local服务器包含或不包含他想访问的资源。
如果您的REST服务器意图拥有通用的可访问资源，那么除非请求正确的URL，否则您应该使用找不到的资源进行响应。
完全可以接受的是，您有一种情况，在本地计算机上有另一台REST服务器，而在Internet上有另一台服务器。 REST客户端将指定他想访问的任何一个。
这就是说，这是不是最好的设计有很多不同的URL引用相同的资源。因此，使用api.local没有任何问题，但在api.local和api引用不同的资源时最好允许这样的事情。
URL代表“统一资源定位器”，而不是“通用资源定位器”。 URL中没有暗示它应该是“全局”或“普遍”可访问的。所以我没有发现本地测试的* .local问题（对于我来说，有一个测试或开发环境可以从任何地方访问）对我来说肯定不好。
我不认为一个URL需要是全局或全局可访问的，但不应该相同的URL总是指向相同的东西？ （不管是否可以访问） – mjs 2010-06-24 06:49:24
啊，我明白你说的是什么，一台计算机上的“xyz.local”可能与另一台计算机上的“xyz.local”不同。我认为，从最严格的意义上讲，但从务实的角度来看，这并不总是可能的...... – 2010-06-24 06:51:45
“只有一个URL应该返回资源”背后的主要实际问题之一是因为对缓存的影响。 如果你有两个相同资源的URL，那么你最终可以在缓存中获得两个副本。如果你对它们中的一个做PUT，那么缓存应该使两者无效，但是它不知道这两个副本之间的关系。
关于您使用的主机名可能会根据解除引用的位置解析为不同的字节流的问题，我并不认为这是一个问题。从概念上讲，您正在访问相同的资源，它实际上只是该资源的另一个实例。我广泛使用它作为发现机制的一种形式。我开发了一个托管在我称为“TMServer”的服务器上的企业应用程序。在一个组织内，只有一个TMServer实例，并且从该主机访问所有资源。例如http://TMServer/Suppliers在我的其他客户之一，该同一个URL将解析为完全不同的供应商集合，但它在概念上仍然是“供应商列表”。
如果我的其中一位顾客试图与另一家公司分享一个网址，那么该网址需要扩展为http://TMServer.company.com/Suppliers。然后这成为一个普遍唯一的URI。
通过使用DNS别名，我可以轻松地使用我的.hosts文件重定向TMServer指向的位置进行测试，并通过在DNS服务器中添加条目我可以向网络上的所有用户广播服务的可用性。
好的一点是，URL不是RESTful。也许我真的在问，“* .local”这个URL是否应该被称为URL。 （我承认这是一个极其棘手的问题！） 也许有关URL的规则实际上并不适用于全局，而只是在每个应用程序的范围内。即URL定位应用程序本身内的资源，但不同的应用程序可以引用相同的'api.local'并且由它指代不同的事物，因为他们从未意识到'api.local'在别处以不同的方式被解释。 – mjs 2010-06-24 07:08:59