我知道REST为API提供了很多优势(其架构属性)(例如JSON API),但是我不知道网站是如何受益于RESTful的.作为一个简单的例子考虑登录功能.在REST方式下,可以通过创建一个具有登录对话的Session模型来建模,创建一个新的sesssion,注销摧毁一个会话等等.网址如下所示：
Prefix Verb URI Pattern Controller#Action
new_user_session GET /users/login(.:format) sessions#new
user_session POST /users/login(.:format) sessions#create
destroy_user_session DELETE /users/sign_out(.:format) sessions#destroy
但是,这些URL不是很友好.从用户的角度来看,只需在登录表单中显示/登录路径就更有意义了.这也更容易记住.但是,如果我们使URL地图如此,那么它们不再是RESTful了;做/登录识别一个资源.如果是这样的话？
另一个例子是主页/ home或只是/.如何适应REST？在大多数网站上,主页是许多不同类型信息的混搭,并不识别任何单一资源.例如,它可以是列出目录中最新产品和您登录的最后一个日期的页面;两个完全无关的事情.那么RESTful呢
我明白为什么将RESTful API与网站分开是有道理的,但我的困惑在于REST如何应用于网站 – 如果它甚至.
解决方法
您所描述的设置需要REST的许多元素,但它本身并不是“REST”,它是为了方便服务器端程序员而设计的一组约定.今天的大多数Web API只使用REST约束的一部分,它是一个不包含网站主要驱动原则的子集.
让我备份一下以下是网站和网络API的共同点：它们都通过资源公开功能.每个资源由URL标识,每个资源都会响应标准HTTP方法的适当子集. (这可能看起来很明显,但看看XML-RPC或SOAP,其中整个系统只有一个URL.)资源可能会向客户端发送文档(响应GET请求)和/或可能接受文档客户端(以及POST或PUT请求).
现在,差异. Web API经常将四种最常见的HTTP方法(POST,GET,PUT,DELETE)映射到四个CRUD操作(创建,读取,更新和删除)中.网站不能这样做,因为网站运行在HTML上,HTML表单只支持两种方法：GET和POST.然而,一个网站可以轻松地描述各种行为 – “搜索”,“下一页”,“购买”,“不友好” – 这些操作非常重要,可以映射到CRUD.
这是因为HTML支持链接和表单.这是家庭树的“Web API”分支中缺少的内容.不是资源,而是资源之间的机器可读连接. (要删除一些REST术语,这是“超媒体约束”或“超媒体作为应用程序状态的引擎”).
“Web API”倾向于忽略超媒体限制,因为a)很难理解,b)JSON不支持链接或表单,因此即使您愿意,也难以遵守超媒体约束. (随着格式如JSON-LD,Hydra和HAL的发展而改变.)
但是,超媒体约束在字面上是什么把Web连在一起.拿走链接和表格,你会留下一个不可用的混乱.
Python Challenge是非RESTful网站的一个很好的例子.你得到a starting URL,然后你必须解决一个小小的难题,弄清楚如何到达下一个URL的顺序.您仍然拥有资源,每个资源都有一个URL.但是资源之间的联系是模糊的.这是一个有趣的游戏,但没有人会以这种方式运行一个严肃的网站.不幸的是,这是我们在“Web API”方面的一个方面.
进一步阅读
你可以说,这是一个复杂的话题.有可能冒犯自己的角,the “maturity model”我开发了一个2008年的谈话可能会帮助您了解万维网(3级)和今天的大多数API(2级)之间的架构差异.我还建议Steve Klabnik的Designing Hypermedia APIs和我自己的RESTful Web APIs,它将Web API与完全一样的网站进行比较.
我早期的书RESTful Web Services也涵盖了这个主题,可以在线阅读.然而,它有点过时了(2007年发表),回想起来,我不认为它足够强大的超媒体角度.
杂
简单地回答一下你原来的问题的一些细微点：
> Web API和网站之间没有技术上的区别.一个网站是一个Web API,正好提供HTML文档.
>一个URL不是比另一个URL更“RESTful”.这只是一个可用性问题.在技术层面上,您的网址看起来并不重要. /users/login.json和/ login和/the-first-100-prime-numbers.gif都是同样RESTful的方法来引用登录表单.
>主页是一个资源：它是一个“主页”资源.它的工作是包含最重要的信息,并指导客户到其他页面 – 直接通过链接,或间接通过搜索表单.资源不一定对应于数据库中的行或对象模型中的对象.一个资源可以是绝对的任何东西,甚至一个现实世界的对象或一个抽象的概念.唯一的限制是资源必须有一个URL.
> / login是一个URL,所以是的,它标识一个资源.什么样的资源？如果发送“GET /登录”可以获得一个带有登录表单的HTML页面的典型场景,那么它是一个“登录表单”资源.如果填写登录表单会触发“POST /登录”请求,那么它也将作为一个“登录表单处理程序”资源.
在对URL进行请求时运行的代码,而不是尝试将其映射到数据集中的一个特定“事物”,可能会更好地考虑资源.也就是说,不是想弄清楚资源是什么,而是根据它的作用来考虑它.
希望这可以帮助.