我刚刚开始尝试理解 REST 设计原则，并且对我正在尝试的第一个示例感到困惑。
假设我想做的是为 SSH session 之类的东西设计一个 REST API。忽略安全、登录等，我假设会有类似/sessions URI 的东西，我通过向/sessions 发布指定连接信息、主机名、用户名之类的东西来启动 SSH session 。这将导致服务于 REST API 的 Web 服务器代表我启动 SSH session ，为其分配某种 ID 并返回/sessions/[id] 的 URI。然后，我可以使用该 URI 的子资源与该 session 进行交互。这不是我想要做的一个非常好的类比，但它有一个要点，即尝试为具有“ session ”的事物定义一个接口(interface)，并且当我将事物发布到资源时其状态会发生变化在其中。
现在我的问题是它的可扩展性，但我想不出更好的办法。它依赖于启动与主机的 SSH 连接的 Web 服务器，并且该连接必须由 Web 服务器维护(如果 Web 服务器必须被回收，则会丢失)。它还将我的请求与单个 Web 服务器联系起来——我不能轻易地拥有一个处理 API 请求的 Web 服务器场。
我可以将 SSH 连接的创建和维护转移到另一台服务器上，但这只会真正解决可伸缩性问题。无论如何，然后我需要为该服务器定义一个 API，为什么不将其设为 REST API，在这种情况下，我只是得到了第一个 API 的副本，无穷无尽。
现在我可能只是以错误的方式看待这个问题，不够以资源为中心，但在我看来，这里的“资源”是 SSH 连接。我的问题是资源不是容易共享的东西——它是网络服务器创建的东西，本质上是暂时的。
是否有任何 RESTful API 设计大师愿意帮助我走上更好的道路？
请注意，我实际上并不认为这真的是 REST 特定的——基本的设计问题会发生，我想我曾经采取什么方法将其设计为 Web 服务，基于 Web 服务交互趋于无状态。
谢谢。
[编辑:] 这种方法的另一个问题是当客户端没有明确删除它们时“ session ”资源的“泄漏”。我能想到的最明智的解决方案是定义 session 的某些属性(可能在创建时设置，也可能是固定的)，它定义了在 session 被视为陈旧和删除之前需要再次联系 session 的时间。客户端将访问此属性(例如/sessions[id]/keepalive 或其他东西)，该属性将返回一个时间戳，将其除以二(在现在和那时之间取一个时间点)并确保如果没有其他内容，它会“轮询”通过在该时间之前再次访问相同的资源来访问服务器。如果失败，则 session 将被回收。
这是我能想到的最“RESTful”的方法，但会重视任何更有经验的 RESTful 思想。
最佳答案
通常为了能够将某些东西声明为资源，它需要存储在某种持久性存储中，或者它应该易于重现。
正如您所说， session 是尝试和建模为资源的非常短暂的事情。它也是通常与单个客户端相关联的东西。然而，资源通常是共享的，这是为其分配公共(public) URI 的原因之一。所有这一切都表明您正在尝试将圆钉安装在方孔中。
话虽如此，如果您真的想这样做，并且想要横向扩展，那么我可以想到两种可能的方法。一种是在单个“DB”服务器上启动 session 。这将允许您横向扩展 Web 服务器。根据大部分工作在哪里完成，这可能有也可能没有任何值(value)。
另一种选择是利用超媒体允许您将 Web 服务器用作 session 发起者，但您需要确保 Web 服务器主机名是 session 资源 URI 的一部分。 REST 客户端不应该对 URI 做出任何假设，并且应该始终从之前的响应中读取它们。如果您利用此优势，您可以在各种 Web 服务器上分发 session ，客户端只需按照 URL 查找 session ，而不管它位于哪个 Web 服务器上。
关于web-services - 具有固有 "sessions"的事物的 RESTful 接口(interface)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4517980/