很久以前就听说过RESTFul这个概念了，但是一直理解不明白。
我已阅读以下链接：
What are RESTful web services?
What exactly is RESTful programming?
据我了解，RESTFul 意味着 URL 不应包含任何动词，这意味着 URL 代表唯一资源。而且，方法 GET 不应该修改任何资源，我们应该使用 POST 来这样做。
但我还有一个问题。
例如，如果我们想按用户名搜索用户，我们可以这样设计 URL：
www.example.com/user?name=test
或者像这样：
www.example.com/user/name/test
你能告诉我哪一个是 RESTFul 的吗？
【问题讨论】：
标签： rest web restful-architecture
当您使用休息时 - 您通过 URI 访问资源，您可以通过 HTTP 请求类型对这些资源设置操作。
您可以通过 REST 请求传递不同的参数，可以是资源标识符（通常通过 URI 传递 - 在您的情况下 www.example.com/user/name/test 更完整）或其他东西当您想要搜索时，例如过滤器，例如 www.example.com/user/?age=....
在这篇文章中，您可以找到更多关于在 rest 中传递参数的最佳实践： REST API Best practices: Where to put parameters?
【讨论】：
首先，REST 不是一种协议，而只是一种架构风格，当正确遵循这种风格时，可以将客户端与服务器 API 分离，从而使它们能够容忍在服务器端进行的更改。因此，它应该被视为分布式系统的一种设计方法。
协议和架构风格之间的区别只是前者定义了服务器或客户端必须遵循的规则集。它应该尽可能精确地定义，以减少歧义，从而减少不同供应商实施不兼容的可能性。后者仅包含如何设计整个应用程序和/或消息流的建议，并概述了坚持设计所获得的好处。
根据该定义，REST 是用于浏览 Web 内容的交互风格的概括。 Web 浏览器能够使用多种协议，例如 HTTP、FTP、SMTP、IMAP ......以及它的不同风格，同时保持独立于任何服务器特定实现，尽管能够在通信完成时与之交互使用的协议的规则。 REST 确实遵循了这种方法，它建立在相同的协议（通常只是 HTTP）上，实现 RESTful 架构方法的应用程序也应该遵守这些协议，以与该协议的其他用户保持兼容。
类似于 Web 浏览器，它不关心 URI 字符串是否包含任何语义结构，REST 也不关心 URI 是如何设计的，也不关心资源是否以动词命名。两者都将使用 URI 来调用提供资源的服务器上的资源。因此，RESTful 客户端不应期望某个 URI 返回某个类型 (= typed resources)。虽然客户端如何知道调用的 URI 将返回什么？这里的关键字是content-negotiation和media-types。
Web 浏览器和 REST 交换的格式是在客户端和服务器之间协商的。虽然对于典型的 Web 浏览器，表示可能是 HTML 变体之一（即 XHTML、HTML 5、...），但并不限于此。您的浏览器可能也能够处理其他媒体类型，即图片、视频、PDF ......由于 REST 只是这个想法的概括，它也不应该仅限于 XML 或 JSON。
因此，媒体类型是关于如何处理和解释以媒体类型概述的表示格式接收的数据的某种准则。它应该定义接收到的有效载荷的语法和语义，例如text/html，它定义了接收到的表示将在内容开头附近有一个不区分大小写的<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 之类的东西。
有关 RESTful API 应密切遵循设计的更多信息和原因，请参阅 Roy Fielding 著名的博文explains some of the constraints，如果 API 遵循 RESTful 方法，则应遵循该博文。
【讨论】：
RESTresource 是一个名词，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 - 这是制作可查询 api 的标准。 OData-like 解决方案是：
/users?$filter=name eq 'test'
Facebook APIs 也是一个很好的灵感来源。
希望对你有帮助
【讨论】：