RESTFul是否意味着URL不应包含参数
[英]Does RESTFul mean URL shouldn't contain parameters
问题描述
I've heard about the conception RESTFul for a long time but I always can't understand it clearly. 
我很早就听说过RESTFul的概念，但是我始终不清楚。
I've read the links below: 我已阅读以下链接：
What are RESTful web services? 什么是RESTful Web服务？
What exactly is RESTful programming? RESTful编程到底是什么？
As my understanding, RESTFul means that the URL shouldn't contain any verb, meaning that an URL represents an unique resource. 据我了解，RESTFul表示URL不应包含任何动词，这意味着URL表示唯一资源。 And also, the method GET shouldn't modify any resource and we should use POST to do so. 而且，GET方法不应修改任何资源，而我们应该使用POST进行修改。
But I still have a question. 但是我还有一个问题。
For example, if we want to search a user by his name, we can design the URL like this: 例如，如果我们想按用户名搜索用户，则可以设计如下URL：
www.example.com/user?name=test
Or like this: 或像这样：
www.example.com/user/name/test
Can you tell me which one is RESTFul? 您能告诉我RESTFul是哪一个吗？
3 个解决方案
解决方案1
1 2017-10-21 06:13:40
When you are using rest - you are accessing resources through URI's and you can set actions on these resources through the HTTP request types. 使用rest时-您正在通过URI访问资源，并且可以通过HTTP请求类型对这些资源设置操作。
There are different parameters that you can pass through REST request , there can be resource identifiers (That are usually passed through the URI - in your case the www.example.com/user/name/test is more restfull) or things like filters when you want to search, for example www.example.com/user/?age=.... 您可以通过REST请求传递不同的参数，可以有资源标识符（通常通过URI传递-在您的情况下，www.example.com / user / name / test更充实）或过滤器等您要搜索的内容，例如www.example.com/user/?age = ....
In this post you can find more about best practices in passing parameters in rest: REST API Best practices: Where to put parameters? 在本文中，您可以找到有关在静止状态传递参数的最佳实践的更多信息： REST API最佳实践：将参数放在哪里？
解决方案2
1 2017-10-21 16:13:04
REST, to start with, is not a protocol but just an architectural style that when followed correctly decouples clients from server APIs and thus make them tolerant to changes done on the serverside. 首先，REST并不是一种协议，而只是一种体系结构样式，如果遵循正确，它将客户端与服务器API分离开来，从而使它们可以容忍服务器端所做的更改。 It should therefore be regarded as a design approach for distributed systems. 因此，应将其视为分布式系统的设计方法。
The difference between a protocol and an architectural style is simply that the former one defines a rule set a server or client has to follow. 协议和体系结构样式之间的区别只是前者定义了服务器或客户端必须遵循的规则集。 It should be defined as precise as possible to reduce ambiguity and thus reduce the likelihood of incompatible implementations by different vendors. 应该尽可能精确地定义它，以减少歧义，从而减少不同供应商实施不兼容的可能性。 The latter one just contains suggestions how to design the overall application and/or message flow and outlining the benefits one gains by adhering to the design. 后者仅包含有关如何设计整个应用程序和/或消息流的建议，并概述通过坚持设计而获得的好处。
By that definition, REST is a generalization of the interaction style used for browsing Web content. 根据该定义，REST是用于浏览Web内容的交互样式的概括。 A Web browser is able to make use of multiple protocols such as HTTP, FTP, SMTP, IMAP, ... and different flavors of it while remaining independant of any server specific implementation though being capable of interacting with it as the communication is done according to the rules of the protocol used. Web浏览器能够使用多种协议（例如HTTP，FTP，SMTP，IMAP等）以及其不同的风格，尽管在通信完成后能够与之交互，但它仍然独立于任何服务器特定的实现。遵守所使用协议的规则。 REST does follow this approach by building up on the same protocols (most often just HTTP) which an application implementing the RESTful architeturce approach should adhere to as well to stay compatible with other users of that protocol. REST确实遵循此方法，建立在实现RESTful体系结构方法的应用程序应遵循的相同协议（通常是HTTP）上，并与该协议的其他用户保持兼容。
Similar to a Web browser, which does not care whether the URI string contains any semantical structure, REST doesn't care how the URI is designed or if the resource is named after a verb either. 与Web浏览器类似，它不在乎URI字符串是否包含任何语义结构，REST也不关心URI的设计方式或资源是否以动词命名。 Both will use the URI just to invoke a resource on the server providing the resource. 两者都将使用URI只是在提供资源的服务器上调用资源。 A RESTful client should thus not expect a certain URI to return a certain type (= typed resources ). 因此，RESTful客户端不应期望某个URI返回某个类型（= 类型化资源 ）。 Though how will a client know what an invoked URI will return? 尽管客户端如何知道调用的URI将返回什么？ The keywords here are content-negotiation and media-types . 这里的关键字是内容协商和媒体类型 。
The format exchanged by both, Web browser and REST, is negotiated between client and server. Web浏览器和REST交换的格式是在客户端和服务器之间协商的。 While for typical Web browsers the representation is probably one of the HTML variants (ie XHTML, HTML 5, ...) it is not limited to it. 尽管对于典型的Web浏览器，表示形式可能是HTML变体之一（例如XHTML，HTML 5，...），但不限于此。 Your browser is probably capable of processing other media types as well, ie pictures, videos, PDF, ... As REST is just a generalization of this idea it also should not limit itself to just XML or JSON. 您的浏览器可能也能够处理其他媒体类型，例如图片，视频，PDF等。由于REST只是这种想法的概括，它也不应该仅限于XML或JSON。
Media types are thus some kind of guildlines of how to process and interpret data received in a representation format outlined by the media type. 因此，媒体类型是有关如何处理和解释以媒体类型概述的表示格式接收的数据的某种准则。 It should define the syntax and semantics of a received payload ie like text/html , which defines that a received representation will have a case-insensitive <html token ( <xhtml in case of XHTML) near the beginning of the content and that fragment identifiers ( # character in URIs) are according to URI semantics and that certain tags like A , IMG or others may define a name attribute which act as a target for anchors. 它应该定义接收到的有效载荷的语法和语义，例如text/html ，它定义接收到的表示形式在内容的开头附近具有不区分大小写的<html标记（对于<xhtml ，为<xhtml ）和片段标识符（URI中的#字符）是根据URI语义而定的，并且某些标记（例如A ， IMG或其他标记）可以定义名称属性，以用作锚点的目标。 It may also define a more thorough description of the syntax and how to interpret it like in case of text/vcard (vCard) (or one of its variants like application/vcard+json (jCard) or application/vcard+xml (xCard) ). 它还可能会定义更完整的语法说明，以及如何解释该语法，例如在text/vcard （vCard） （或其变体之一，例如application/vcard+json （jCard）或application/vcard+xml （xCard））的情况下 ）。
As media types are one of the most important parts of the RESTful design, most effort has to be put into its creation. 由于媒体类型是RESTful设计中最重要的部分之一，因此必须在创建过程中付出最大的努力。 A client that can't deduct the next possible actions from the media type needs some out-of-band information which often is hardcoded into the client and thus couples it tightly to the API itself. 无法从媒体类型中推断出下一步可能采取的措施的客户端需要一些带外信息，这些信息通常被硬编码到客户端中，因此将其紧密地耦合到API本身。 If the API will change in future, the chances that the client will stop working once the changes are applied on the server are fairly high (depending on the changes). 如果API将来会更改，则一旦将更改应用到服务器后，客户端将停止工作的机会就很大（取决于更改）。
I hope I could shed some light on the idea behind REST and that the design of URI is not of relevance to a true RESTful client/API as the client might deduct what to do with that URI based on some relation name returned for the URI and the media-type which might state that a relation name such as order can be invoked to trigger a new order with the API rather than having the client to analyze something like http://some.server.com/api/order/product/1234 or http:/some.server.com/ajfajd/fj/afja . 我希望我能对REST背后的想法有所了解，并且URI的设计与真正的RESTful客户端/ API不相关，因为客户端可能会基于为URI返回的某些关系名称来推断对该URI进行处理。媒体类型可能声明的关系的名字，如order可以被调用来触发与API新秩序，而不是客户端来分析类似http://some.server.com/api/order/product/1234或http:/some.server.com/ajfajd/fj/afja 。
Further information and reasons why RESTful APIs should follow the design closely can be found in Roy Fielding famous blog post which explains some of the constraints an API should adhere to if it follows the RESTful approach. Roy Fielding著名的博客文章中提供了更多信息以及RESTful API应该紧跟设计的原因，该文章解释了API如果遵循RESTful方法应遵循的一些约束 。
解决方案3
0 已采纳 2017-10-21 09:42:08
REST resource is a noun, no notion of behavior should be in the uri, we use verbs to indicate action we are doing. REST资源是一个名词，uri中不应包含任何行为概念，我们使用动词来表示我们正在执行的操作。 Basically there are only two types of resources: Instance and Collections. 基本上只有两种类型的资源：实例和集合。 So good practise is to use plurals in the uri: users instead of user : 因此，好的做法是在uri中使用复数： users而不是user ：
www.example.com/users GET - fetch collection of all users www.example.com/users GET获取所有用户的集合
www.example.com/users/1 GET - fetch instance of a concrete user www.example.com/users/1 GET获取具体用户的实例
www.example.com/users POST - create of a new user etc. www.example.com/users POST创建新用户等
REST is not a strict standard (but a list of 6 constraints ) says nothing about how search feature should be implemented. REST并不是一个严格的标准（但是有6个约束的清单）没有说明应如何实现搜索功能。 But definetely your first option /users?name=test seems preferable for me: tt is straightforward and this is a huge benefit. 但是绝对地，您的首选/users?name=test对我来说似乎更可取：tt很简单，这是一个巨大的好处。
As alternative you may want to investigate OData protocol - it is a standard to make queryable apis. 或者，您可能想研究OData协议 -这是制作可查询api的标准。 OData -like solution would be: OData的解决方案是：
/users?$filter=name eq 'test'
Also Facebook APIs is a good source for inspiration. 同样， Facebook API是灵感的良好来源。
Hope this helps 希望这可以帮助
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.