关于REST URL的详细问题

这是那些小细节（也可能是宗教）问题之一。假设我们正在构建REST架构，并且为了确定服务需要三个参数：x,y和z。阅读关于REST的各项工作，似乎这应该表示为一个URI像关于REST URL的详细问题

X/Ÿ/ž

已经写了很多的CGI的过去，似乎很自然的表达这

http://myservice.example.com/service?x=val,y=val,z=val

是否有什么特别的理由更喜欢使用全斜杠？

来源

2008-12-24 Charlie Martin

您表示URI的方式对REST来说并不重要，只是您知道。这只是关于HTTP的一个问题。 – aehlke 2009-08-11 19:30:41

原因很小，但在这里。

酷URI的不改变。

http://myservice.example.com/resource/x/y/z/形式在上帝和大家面前宣称，这是通向特定资源的路径。

请注意，我更改了名称。可能涉及到服务，但REST原则是您正在描述一个名为/x/y/z/的特定Web资源。

该http://myservice.example.com/service?x=val,y=val,z=val形式不会造成强烈的索赔。它说有一个代码service将尝试做某种查询。没有保证。

来源

2008-12-24 01:56:38

这个答案是非常荒谬的。 “酷URI的不要改变”与这个问题无关。如上所述，这两个例子都可以在任何时候完全使用，因此是不会改变的URI。 – webjunkie 2009-02-10 20:46:22

@webjunkie。 /服务不是一个很酷的URI，它需要额外的查询字符串是有意义的。查询字符串不应被认为是URI的头等部分。 – 2009-02-10 20:56:58

@ S.Lott“服务”显然是一个占位符，就像x y z一样。你把一个真正的服务名称放在它给出URI意义的地方。 – webjunkie 2009-02-10 23:03:55

如果资源是独立的参数的服务，它应该是

http://myservice.example.com/service?x=val&y=val&z=val

这是一个GET查询。 REST背后的原理之一是您可以阅读（但不能修改！）资源;你可以通过POST来修改资源&得到响应;你可以PUT写入资源;并且您可以删除以删除资源。

如果这些参数特定的资源是永久性资源，它需要一个名称。您可以（如果您以这种方式组织Web服务）POST到http://myservice.example.com/service?x=val&y=val&z=val以创建该服务的特定实例，并让它返回一个ID来命名该实例，例如，

http://myservice.example.com/service/12312549

然后使用GET/POST/PUT/DELETE与该实例进行交互。

来源

2008-12-24 03:44:01

查询参数很少“酷”。看看Google Chart API。是否应该为所有字段使用一个/完整/路径/符号？每个URL都会很酷吗？

查询参数很有用。可选字段可以省略。可以添加新密钥以支持新功能。随着时间的推移，旧字段可能会被弃用和删除。这样做是笨拙的/路径/符号。

从报价http://www.xml.com/pub/a/2004/08/11/rest.html

URI不透明度[BP]

URI的创建者决定的URI的编码，用户不能从URI本身导出元数据。 URI不透明度仅适用于URI的路径。查询字符串和片段有特殊的意思是用户可以理解。服务与其消费者之间必须有一个共享词汇表。

这听起来像查询字符串是你想要的。

查询字符串的一个缺点是它是无序的。以“？x = 1 & y = 2”结尾的GET与以“？y = 2 & x = 1”结尾的GET不同。这意味着浏览器和其他中间系统将无法缓存它，因为缓存是基于完整的URL完成的。如果这是一个问题，那么按照定义良好的顺序生成查询字符串。

来源

2009-02-10 15:39:48

-1

带有类似/x/y/z/这样的斜线的网址会强加一个层次结构，并不适合传递三个参数的确切情况。

如果像你说的，某某确实只是参数和顺序并不重要，它会更RESTful的使用分号：

http://myservice.example.com/service/x;y;z/

如果你的“服务”，然而就是这样工作的算法使用?x=val格式也不会有什么不可靠的。

来源

2009-02-10 15:54:29 webjunkie

在构建URI时，这是我遵循的原则。我不知道它是否在所有的情况下

例如说完全可以接受的，我必须得到员工的详细信息，那么URI会是这样的形式：

GET /员工/ 1/而不是GET/employees？id = 1因为我将每个员工视为资源，并且整个URI“employees/{id}”用于识别资源。另一方面，如果我的算法运算不能识别特定的资源，而只是需要对算法进行识别资源的输入，那么我使用查询字符串。

比如GET /员工？empname =“％鲍勃％” &的maxResults = 100会给我的名字在他们的字鲍勃全体员工，由仅限于100

查询返回的最大成果

希望能回答你的问题

来源

2009-02-17 10:50:14 Prashanth

首先，将URI定义为API的一部分违反了REST体系结构的约束条件。你不能这样做，并调用你的API RESTful。

其次，原因查询参数对非查询资源访问不利的原因是它们通常不被缓存。这也违反了HTTP标准。

来源

2009-07-20 19:13:49 aehlke

URI是严格划分为分层部分（路径）和非分层路径（查询），并既用于识别资源

里边反URI规范本身（RFC 3986）明确规定的路径和URI的查询部分相等。

3.3节：

路径组件包含数据[...]与[的]沿查询组件用于标识一个资源。

第3.4节：

查询组件包含[...]数据，连同 [...]路径组件用来标识资源

所以在使用x/y/z与x=val&y=val&z=val时，您的选择主要是在x，y或z本质上是分层结构还是非分层结构，并且如果您能够在可预见的将来一直认为它们是分层结构或非分层结构，与y您可能在选择其中一项时遇到的技术限制。

但是要回答你的问题，正如其他人所指出的那样：既不是RESTful，也不是RESTful，因为它们最终都会识别资源。

来源

2010-08-01 19:40:49 mogsie

关于REST URL的详细问题

回答

相关问题