ruby-on-rails - RESTful 网站与 RESTful API - 有什么区别，重要吗？

Question

我一直在阅读很多关于 REST 以及如何以“正确的方式”进行 REST 的文章。大多数资源使用诸如 RESTful Web 服务或 RESTful API 之类的术语，但没有提到 RESTful 网站。鉴于我将网站和 API 视为两种不同的事物，我对此感到困惑。然而，例如，当使用 Rails 框架设计网站时，您会不断地意识到一切都是(或应该是)RESTful。

我知道 REST 为 API(例如 JSON API)提供了很多优势(其架构属性)，但我只是不明白 网站从 RESTful 中受益。作为一个简单的例子，考虑登录功能。在 REST 方式中，这可以通过创建一个 Session 模型来建模，其中登录对应于创建一个新 session ，注销销毁 session 等等。这些 URL 看起来像这样:

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 对用户不是很友好。从用户的角度来看，只有一个显示登录表单的/login 路径更有意义。也更容易记住。但是如果我们像这样映射 URL，它们就不再是真正的(作为)RESTful；/login 是否识别资源。如果有，是哪一个？

另一个例子是主页/home 或只是/。这如何适应 REST？在大多数网站上，主页是多种不同类型信息的混搭，不标识任何单一资源。例如，它可以是一个页面，其中列出了目录中的最新产品和您最后登录的日期；完全不相关的两件事。那是怎样的 RESTful？

我明白为什么有一个 RESTful API 与网站分开是有道理的，但我的困惑在于 REST 如何应用于 网站 - 如果它甚至。

Answer 1

简短的回答是没有人谈论 RESTful 网站，因为网站默认是 RESTful。您真的必须尝试制作一个非 RESTful 网站(尽管它已经完成——见下文)。

您所描述的设置从 REST 中获取了很多元素，但它本身并不是“REST”:它是一组为方便服务器端程序员而设计的约定。当今的大多数 Web API 仅使用 REST 约束的一个子集，并且该子集不包括网站背后的主要驱动原则。

让我退后一点。以下是网站和 Web API 的共同点:它们都通过资源公开功能。每个资源都由一个 URL 标识，每个资源都响应标准 HTTP 方法的适当子集。 (这似乎很明显，但看看 XML-RPC 或 SOAP，其中整个系统只有一个 URL。)资源可能会向客户端发送文档(响应 GET 请求)和/或它可能接受来自客户端(以及 POST 或 PUT 请求)。

现在，差异。 Web API 通常将四种最常见的 HTTP 方法(POST、GET、PUT、DELETE)映射到四种 CRUD 操作(创建、读取、更新、删除)。网站不能这样做，因为网站运行在 HTML 上，而 HTML 表单只支持两种方法:GET 和 POST。然而，一个网站可以很容易地描述各种 Action ——“搜索”、“下一页”、“购买”、“取消好友”——这些 Action 映射到 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 并不比另一个更“RESTful”。这仅仅是一个可用性问题。在技​​术层面上，您的 URL 的外观完全无关紧要。 /users/login.json和 /login和 /the-first-100-prime-numbers.gif都是同样 RESTful 的方式来引用登录表单。

主页是一种资源:它是一个“主页”资源。它的工作是包含最重要的信息位，并引导客户到其他页面——直接通过链接，或间接通过搜索表单。资源不一定对应于数据库中的一行或对象模型中的对象。资源绝对可以是任何东西，甚至可以是现实世界的对象或抽象概念。唯一的限制是资源必须有一个 URL。

/login是一个 URL，所以是的，它标识了一个资源。什么样的资源？如果这是发送“GET/login”为您提供带有登录表单的 HTML 页面的典型场景，那么它就是“登录表单”资源。如果填写登录表单触发“POST/login”请求，那么它也充当“登录表单处理器”资源。

您可能会更幸运地根据请求其 URL 时运行的代码来考虑资源，而不是尝试将其映射到数据集中的一个特定“事物”。也就是说，与其试图弄清楚资源是什么，不如根据它的作用来思考它。

希望这可以帮助。