我很长一段时间都听说过RESTFul这个概念,但我总是无法理解它。
我已阅读以下链接:
What are RESTful web services?
What exactly is RESTful programming?
根据我的理解,RESTFul意味着URL不应包含任何动词,这意味着URL表示唯一的资源。而且,GET方法不应该修改任何资源,我们应该使用POST来实现这一点。
但我还有一个问题
例如,如果我们想通过他的名字搜索用户,我们可以设计如下的URL:
www.example.com/user/name/test
或者像这样:
{{1}}
你能告诉我哪一个是RESTFul吗?
答案 0 :(得分:1)
当您使用休息时 - 您正在通过URI访问资源,您可以通过HTTP请求类型设置对这些资源的操作。
您可以通过REST请求传递不同的参数,可以有资源标识符(通常通过URI传递 - 在您的情况下www.example.com/user/name/test更加安静)或者事物比如想要搜索的过滤器,例如www.example.com/user/?age = ....
在这篇文章中,您可以找到更多关于在休息中传递参数的最佳实践: REST API Best practices: Where to put parameters?
答案 1 :(得分:1)
REST,首先,它不是一种协议,而只是一种架构风格,在遵循时正确地将客户端与服务器API分离,从而使它们能够容忍在服务器端进行的更改。因此,它应被视为分布式系统的设计方法。
协议和架构风格之间的区别仅在于前者定义了服务器或客户端必须遵循的规则集。应尽可能精确地定义它以减少歧义,从而降低不同供应商不兼容实现的可能性。后者仅包含如何设计整体应用程序和/或消息流的建议,并概述了通过遵循设计而获得的好处。
根据该定义,REST是用于浏览Web内容的交互方式的概括。 Web浏览器能够利用多种协议,例如HTTP,FTP,SMTP,IMAP ......以及它的不同风格,同时保持独立于任何服务器特定的实现,尽管能够与它进行交互,因为通信是根据遵守所用协议的规则。 REST确实遵循这种方法,建立了相同的协议(通常只是HTTP),实现RESTful architeturce方法的应用程序应该遵守该协议,以便与该协议的其他用户保持兼容。
类似于Web浏览器,它不关心URI字符串是否包含任何语义结构,REST不关心如何设计URI或者资源是否以动词命名。两者都将使用URI来调用提供资源的服务器上的资源。因此,RESTful客户端不应期望某个URI返回某种类型(= typed resources)。虽然客户端如何知道调用的URI将返回什么?这里的关键字是内容协商和媒体类型。
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
或{{1 }}
RESTful API应该密切关注设计的更多信息和原因可以在Roy Fielding着名的博客文章中找到,如果它遵循RESTful方法,explains some of the constraints API应该遵守。
答案 2 :(得分:0)
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
- 就像解决方案一样:
/users?$filter=name eq 'test'
Facebook APIs也是一个很好的灵感来源。
希望这有帮助