我已经听说了RESTFul很长一段时间的概念，但我总是无法清楚地理解它。
RESTFul的意思是URL不应该包含参数
我读过下面的链接：
What are RESTful web services?
What exactly is RESTful programming?
至于我的理解，基于REST意味着该网址中不应包含任何动词，意思是一个URL代表一个独特的资源。而且，GET方法不应该修改任何资源，我们应该使用POST来完成。
但我仍然有一个问题。
例如，如果我们想通过自己的名字来搜索用户，我们可以设计的URL是这样的：
www.example.com/user?name=test
或者这样：
www.example.com/user/name/test
你能告诉我哪一个是RESTFul？
REST资源是一个名词，没有行为的概念应该在uri中，我们用动词来表示我们正在做的动作。基本上只有两种类型的资源：实例和集合。所以，比较好的做法是在URI中使用复数：users代替user：
www.example.com/users GET - 获取所有用户
www.example.com/users/1 GET的收集 - 获取一个具体的用户实例
www.example.com/users POST - 新用户的创建 等
REST不是一个严格的标准（但列表6 constraints）没有说如何实现搜索功能。但是确定你的第一个选择/users?name=test对我来说似乎更可取：tt很直接，这是一个巨大的好处。
作为替代方案，您可能需要调查OData protocol - 这是制定可查询apis的标准。 OData样的解决办法是：
/users?$filter=name eq 'test'
另外Facebook APIs为灵感的良好来源。
希望这有助于
当您使用rest时 - 您通过URI访问资源，并且可以通过HTTP请求类型设置对这些资源的操作。
您可以通过REST请求传递不同的参数，可以有资源标识符（通常通过URI传递 - 在您的情况下www.example.com/user/name/test更为安全）或当您想要搜索，例如www.example.com/user/?age = ....
在这篇文章中，你可以找到更多关于最佳做法，在其他参数传递之类的东西过滤器： REST API Best practices: Where to put parameters?
REST，下手，是不是一个协议，但只是一种架构风格，随后当正确解耦服务器API客户端，从而使他们宽容对服务器端进行修改。因此应该将其视为分布式系统的设计方法。
协议和体系结构样式之间的区别很简单，前者定义了服务器或客户端必须遵循的规则集。它应该尽可能精确地定义以减少歧义，从而降低不同供应商实施不兼容的可能性。后者仅包含如何设计整体应用程序和/或消息流的建议，并概述了坚持设计带来的好处。
通过该定义，REST是用于浏览Web内容的交互风格的泛化。 Web浏览器能够使用多种协议，例如HTTP，FTP，SMTP，IMAP等...以及它们的不同风格，同时仍然独立于任何特定于服务器的实现，尽管能够与其交互，因为通信是根据遵守所使用协议的规则。 REST确实遵循这种方法，通过建立在实现RESTful结构方法的应用程序应该遵守的相同协议（通常只是HTTP）上，以便与该协议的其他用户保持兼容。
与Web浏览器类似，它不关心URI字符串是否包含任何语义结构，REST不关心URI的设计方式或资源是否以动词命名。两者都将使用URI来调用提供资源的服务器上的资源。因此，RESTful客户端不应该期望某个URI返回某种类型（= typed resources）。尽管客户端如何知道被调用的URI将返回什么？这里的关键字是内容协商和媒体类型。
由Web浏览器和REST两者交换的格式是在客户端和服务器之间协商的。虽然对于典型的Web浏览器，表示可能是HTML变体（即XHTML，HTML 5，...）中的一种，但并不仅限于此。您的浏览器可能也可以处理其他媒体类型，例如图片，视频，PDF等等。由于REST仅仅是这个想法的一个普遍性，它也不应该仅限于XML或JSON。
因此，媒体类型是如何处理和解释以媒体类型概述的表示格式接收的数据的某种类型的指示线。它应该定义接收到的有效负载的语法和语义，例如text/html，它定义接收到的表示将在内容的开始附近具有不区分大小写的标记（在XHTML的情况下为<xhtml），并且该片段标识符（#字符在URI）根据URI语义，并且诸如A,IMG或其他的某些标签可以定义充当锚的目标的名称属性。它还可以定义更详尽的语法描述以及如何解释它，如text/vcard (vCard)（或其变体之一如application/vcard+json (jCard)或application/vcard+xml (xCard)）的情况。
由于媒体类型是RESTful设计中最重要的部分之一，因此大部分工作都必须投入创建。无法从媒体类型中扣除下一个可能操作的客户端需要一些带外信息，这些信息通常会被硬编码到客户端中，从而将其紧密结合到API本身。如果将来API改变，一旦在服务器上应用更改，客户端将停止工作的机会相当高（取决于更改）。
我希望我能阐明REST背后的想法，以及URI的设计与真正的RESTful客户端/ API无关，因为客户端可能会根据返回的某些关系名称推断如何处理该URI对于URI和媒体类型，可能会声明可以调用关系名称（如order）以通过API触发新订单，而不是让客户端分析诸如http://some.server.com/api/order/product/1234或http:/some.server.com/ajfajd/fj/afja之类的内容。
REST风格的API应该严格遵循设计的更多信息和原因可以在Roy Fielding着名的博客文章中找到，如果遵循REST风格的方法，API应遵循explains some of the constraints。