Session REST-复杂应用程序

我正在努力将RESTful原则应用到我正在开发的新web应用程序中。特别是，为了实现RESTful，每个HTTP请求本身都应该携带足够的信息，以便接收方能够处理它，从而与HTTP的无状态特性完全协调

该应用程序允许用户搜索药物。搜索接受过滤器作为输入，例如，返回停用药物，包括免费治疗等。总共大约有30个过滤器可以应用

此外，还可以输入患者详细信息，包括患者年龄、性别、当前药物等

为了保证安全，是否应该在每个请求中包含所有这些信息？这似乎给网络带来了巨大的开销。另外，对URL长度的限制（至少对于GET而言）会不会使这变得不可行呢？

REST是针对API的，而不是（典型的）应用程序。不要仅仅因为你在维基百科上读到它，就试图将一个基本上有状态的交互嵌入到一个无状态的模型中

为了保证安全，是否应该在每个请求中包含所有这些信息？这似乎给网络带来了巨大的开销。另外，对URL长度的限制（至少对于GET而言）会不会使这变得不可行

与服务器发送的资源大小相比，参数的大小通常微不足道。如果您使用的参数太大，以致于它们成为网络负担，请将它们放在服务器上一次，然后将它们用作资源

---

URL长度没有明显的限制——如果您的服务器有这样的限制，请升级它。它可能已经存在多年了，而且到处都是安全漏洞。

您是否正在开发一个RESTful API，其他应用程序将使用它来搜索您的数据？或者您正在构建一个以最终用户为中心的web应用程序，用户将在其中登录并执行这些搜索

如果您的用户正在登录，那么您已经是有状态的，因为您将拥有某种类型的会话cookie来维护登录状态。我将继续创建一个包含所有搜索过滤器的会话对象。如果用户未设置任何筛选器，则此对象将为空

这里有一篇关于使用GET vs post的很棒的博客文章。它提到了InternetExplorer设置的2048个字符的URL长度限制，因此您希望对长请求使用POST

---

不，并非所有这些都必须出现在每个请求中

每个资源（药物、患者病史等）都应该有一个唯一标识它的规范URI。在某些应用程序中（例如，基于Rails的应用程序），这类似于“/patients/1234”或“/druges/5678”，但URL格式并不重要

以前获取过资源URI（例如从搜索或嵌入到另一个资源中的链接）的客户端可以使用此URI检索资源。

使用“作为资源筛选”是一种完美的方法

您可以将过滤器定义放入过滤器资源，它可以返回过滤器ID

PUT是幂等的，所以即使过滤器已经存在，您只需要检测到您以前见过过滤器，这样您就可以为过滤器返回正确的ID

然后，您可以向其他请求添加一个过滤器参数，它们可以获取用于查询的过滤器

获取/使用药物？过滤器=1234，页面=4，页面大小=20

我将通过某种规范化过程来运行原始过滤器，只是为了获得一个规范化集，因此，例如，过滤器“firstname=Bob lastname=Eubanks”与“lastname=Eubanks firstname=Bob”相同。不过那只是我

唯一真正令人担心的是，随着时间的推移，您可能需要淘汰一些过滤器。如果有人提出一个缺少或过时过滤器的请求，您可以简单地将请求出错

编辑回答问题

让我们从基本面开始

简单地说，您希望指定一个用于查询的过滤器，但这些过滤器（可能）涉及且复杂。如果是简单的/药物/1234，这就不会是问题

实际上，您始终需要将筛选器发送到查询。问题是如何表示该过滤器

REST系统中会话之类的基本问题是，它们通常是“带外”管理的。比如说，当你去创建一种药物时，你会把它放到或发布到药物资源中，然后你会得到该药物的引用

对于一个会话，您（通常）会得到一个cookie，或者一些其他令牌来表示该会话。如果您对药物资源的PUT也创建了一个会话，那么实际上，您的请求创建了两个资源：一个药物和一个会话

不幸的是，当您使用cookie之类的东西，并且您的请求需要该cookie时，资源名称不再是资源的真实表示形式。现在是资源名（URL）和cookie

因此，如果我访问名为/medicines/search的资源，cookie表示一个会话，而该会话恰好包含一个过滤器，那么您可以看到，实际上，资源名/medicines/search根本没有什么用处。我没有有效利用所需的所有信息，因为cookie和会话的副作用以及其中的过滤器

现在，您可能可以重写名称：/medicines/search？session=ABC123，有效地将cookie嵌入到资源名称中

但是现在你遇到了一个典型的会话契约，特别是它们是短暂的。所以，那个命名的资源是不太有用的，长期的，不是无用的，只是不太有用。现在，这个查询给了我一些有趣的数据。明天可能不会。我会得到一些关于会议结束的严重错误

另一个问题是会话通常不作为资源进行管理。例如，它们通常是副作用，而不是通过GET/PUT/DELETE显式管理。会话也是“垃圾堆”

# view all Recommendations for the patient
GET http://server.com/patients/{patient}/recommendations

# view all Recommendations for a Medication
GET http://servier.com/medications/{medication}/recommendations

# add a new Recommendation for a Patient
PUT http://server.com/patients/{patient}/recommendations