RESTFul 是否意味着 URL 不应该包含参数
Does RESTFul mean URL shouldn't contain parameters
早就听说了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 时 - 您正在通过 URI 访问资源，您可以通过 HTTP 请求类型对这些资源设置操作。
您可以通过 REST 请求传递不同的参数，可以有资源标识符（通常通过 URI 传递 - 在您的情况下 www.example.com/user/name/test 更安静）或者当你想搜索时像过滤器之类的东西，例如 www.example.com/user/?age=....
在此 post 中，您可以找到有关静态传递参数的最佳实践的更多信息：
REST API Best practices: Where to put parameters?
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 - 它是制作可查询 API 的标准。 OData-like 解决方案是：
/users?$filter=name eq 'test'
另外 Facebook APIs 也是一个很好的灵感来源。
希望对您有所帮助
REST 首先不是一种协议，而只是一种架构风格，当正确遵循时，它会将客户端与服务器 API 分离，从而使它们能够容忍在服务器端所做的更改。因此，它应该被视为分布式系统的一种设计方法。
协议和架构风格之间的区别很简单，前者定义了服务器或客户端必须遵循的规则集。它应该尽可能精确地定义以减少歧义，从而减少不同供应商不兼容实现的可能性。后者仅包含如何设计整个应用程序 and/or 消息流的建议，并概述了坚持设计所获得的好处。
根据该定义，REST 是用于浏览 Web 内容的交互方式的概括。 Web 浏览器能够使用多种协议，例如 HTTP、FTP、SMTP、IMAP ......以及它的不同风格，同时保持独立于任何服务器特定实现，尽管能够与它交互作为通信是根据所用协议的规则进行的。 REST 确实通过构建相同的协议（通常只是 HTTP）来遵循这种方法，实现 RESTful 架构方法的应用程序也应该遵守这些协议，以便与该协议的其他用户保持兼容。
与Web 浏览器类似，它不关心URI 字符串是否包含任何语义结构，REST 也不关心URI 是如何设计的，也不关心资源是否以动词命名。两者都将使用 URI 来调用提供资源的服务器上的资源。因此，RESTful 客户端不应期望某个 URI 到 return 某种类型 (= typed resources)。尽管客户端如何知道调用的 URI 将 return 是什么？这里的关键字是 content-negotiation 和 media-types.
Web 浏览器和 REST 两者交换的格式是在客户端和服务器之间协商的。虽然对于典型的 Web 浏览器，表示可能是 HTML 变体之一（即 XHTML、HTML 5，...），但并不限于此。您的浏览器可能也能够处理其他媒体类型，即图片、视频、PDF ......因为 REST 只是这个想法的概括，它也不应该将自己限制为 XML 或 JSON.
因此，媒体类型是关于如何处理和解释以媒体类型概述的表示格式接收的数据的某种准则。它应该定义接收到的有效载荷的语法和语义，例如 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. 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)).
由于媒体类型是 RESTful 设计中最重要的部分之一，因此必须在其创建中投入大部分精力。无法从媒体类型中推断出下一个可能的操作的客户端需要一些带外信息，这些信息通常被硬编码到客户端中，因此将其与 API 本身紧密耦合。如果 API 将来会发生变化，那么在服务器上应用更改后客户端停止工作的可能性相当高（取决于更改）。
我希望我能阐明 REST 背后的想法，URI 的设计与真正的 RESTful client/API 无关，因为客户可能会推断出如何处理它URI 基于一些关系名称 returned 用于 URI 和媒体类型，这可能表明可以调用诸如 order 的关系名称来触发新订单 API 而不是而不是让客户分析 http://some.server.com/api/order/product/1234 或 http:/some.server.com/ajfajd/fj/afja.
之类的东西
有关 RESTful API 应密切遵循设计的更多信息和原因可以在 Roy Fielding 著名博客 post 中找到，其中 explains some of the constraints 和 API 如果遵循 RESTful 方法，则应遵守。
早就听说了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 时 - 您正在通过 URI 访问资源，您可以通过 HTTP 请求类型对这些资源设置操作。
您可以通过 REST 请求传递不同的参数，可以有资源标识符（通常通过 URI 传递 - 在您的情况下 www.example.com/user/name/test 更安静）或者当你想搜索时像过滤器之类的东西，例如 www.example.com/user/?age=....
在此 post 中，您可以找到有关静态传递参数的最佳实践的更多信息： REST API Best practices: Where to put parameters?
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 - 它是制作可查询 API 的标准。 OData-like 解决方案是：
/users?$filter=name eq 'test'
另外 Facebook APIs 也是一个很好的灵感来源。
希望对您有所帮助
REST 首先不是一种协议，而只是一种架构风格，当正确遵循时，它会将客户端与服务器 API 分离，从而使它们能够容忍在服务器端所做的更改。因此，它应该被视为分布式系统的一种设计方法。
协议和架构风格之间的区别很简单，前者定义了服务器或客户端必须遵循的规则集。它应该尽可能精确地定义以减少歧义，从而减少不同供应商不兼容实现的可能性。后者仅包含如何设计整个应用程序 and/or 消息流的建议，并概述了坚持设计所获得的好处。
根据该定义，REST 是用于浏览 Web 内容的交互方式的概括。 Web 浏览器能够使用多种协议，例如 HTTP、FTP、SMTP、IMAP ......以及它的不同风格，同时保持独立于任何服务器特定实现，尽管能够与它交互作为通信是根据所用协议的规则进行的。 REST 确实通过构建相同的协议（通常只是 HTTP）来遵循这种方法，实现 RESTful 架构方法的应用程序也应该遵守这些协议，以便与该协议的其他用户保持兼容。
与Web 浏览器类似，它不关心URI 字符串是否包含任何语义结构，REST 也不关心URI 是如何设计的，也不关心资源是否以动词命名。两者都将使用 URI 来调用提供资源的服务器上的资源。因此，RESTful 客户端不应期望某个 URI 到 return 某种类型 (= typed resources)。尽管客户端如何知道调用的 URI 将 return 是什么？这里的关键字是 content-negotiation 和 media-types.
Web 浏览器和 REST 两者交换的格式是在客户端和服务器之间协商的。虽然对于典型的 Web 浏览器，表示可能是 HTML 变体之一（即 XHTML、HTML 5，...），但并不限于此。您的浏览器可能也能够处理其他媒体类型，即图片、视频、PDF ......因为 REST 只是这个想法的概括，它也不应该将自己限制为 XML 或 JSON.
因此，媒体类型是关于如何处理和解释以媒体类型概述的表示格式接收的数据的某种准则。它应该定义接收到的有效载荷的语法和语义，例如 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. 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)).
由于媒体类型是 RESTful 设计中最重要的部分之一，因此必须在其创建中投入大部分精力。无法从媒体类型中推断出下一个可能的操作的客户端需要一些带外信息，这些信息通常被硬编码到客户端中，因此将其与 API 本身紧密耦合。如果 API 将来会发生变化，那么在服务器上应用更改后客户端停止工作的可能性相当高（取决于更改）。
我希望我能阐明 REST 背后的想法，URI 的设计与真正的 RESTful client/API 无关，因为客户可能会推断出如何处理它URI 基于一些关系名称 returned 用于 URI 和媒体类型，这可能表明可以调用诸如 order 的关系名称来触发新订单 API 而不是而不是让客户分析 http://some.server.com/api/order/product/1234 或 http:/some.server.com/ajfajd/fj/afja.
有关 RESTful API 应密切遵循设计的更多信息和原因可以在 Roy Fielding 著名博客 post 中找到，其中 explains some of the constraints 和 API 如果遵循 RESTful 方法，则应遵守。