Question

我正在努力将RESTful原则应用于我正在开发的新Web应用程序。特别值得一提的是，要成为RESTful，每个HTTP请求都应该自己携带足够的信息，以便其接收者处理它与HTTP的无状态特性完全一致。

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

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

要安息，是否所有这些信息都包含在每个请求中？这似乎给网络带来了巨大的开销。另外，对于URL长度的限制，至少对于GET来说，这不是不可行的吗？

Answer 1

要保持安静，是否所有这些信息都包含在每个请求中？

没有。如果您的服务器看起来像是在发送（或接收）太多信息，那么您可能还有一个或多个尚未识别的资源。

设计RESTful系统的第一步也是最重要的一步是识别和命名您的资源。你会如何为你的系统做到这一点？

根据您的描述，这里有一组可能的资源：

用户 - 系统的用户（可能是医生或病人（？） - 角色可能需要在此处作为资源公开）
药物 - 瓶子里的东西，但它也可能代表瓶子的种类（数量和含量），或者它可能代表一个特定的瓶子 - 取决于你是药店还是只是一个服务台。
疾病 - 患者可能需要用药的条件。
患者 - 可能参加用药的人
推荐 - Medication ，可能对患者基于他们所患的疾病有益。

然后你可以寻找资源之间的关系;

用户拥有并属于许多角色
药物拥有并属于许多疾病
疾病有许多推荐。
患者拥有并属于许多药物和疾病（可怜的家伙）
患者有许多建议
推荐有一个患者并且有一个疾病

具体细节可能不适合您的特定问题，但想法很简单：在您的资源之间建立关系网络。

此时考虑URI结构可能会有所帮助，但请记住REST APIs must be hypertext-driven：

# 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

因为这是REST，所以您将花费大部分时间defining the media types用于在客户端和服务器之间传输资源的表示。

通过公开更多资源，您可以减少每次请求期间需要传输的数据量。另请注意，URI中没有查询参数。服务器可以像所需的那样有状态地跟踪它，并且每个请求都可以是完全自包含的。

Answer 2

REST适用于API，而非（典型）应用程序。不要试图将基本的有状态交互楔入无状态模型只是因为你在维基百科上阅读它。

要安息，是否所有这些信息都包含在每个请求中？这似乎给网络带来了巨大的开销。另外，对于URL长度的限制，至少对于GET来说，这不是不可行的吗？

与服务器发送的资源大小相比，参数的大小通常无关紧要。如果您使用的是如此大的参数以致它们是网络负担，请将它们放在服务器上一次，然后将它们用作资源。

对URL长度没有重大限制 - 如果您的服务器有这样的限制，请升级它。它可能已经存在了很多年，并且充满了安全漏洞。

Answer 3

并非所有这些都不必存在于每个请求中。

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

以前获取资源URI的客户端（例如来自搜索或嵌入其他资源的链接）可以使用此URI检索它。

Answer 4

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

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

这是一篇关于使用GET vs POST的精彩博文。它提到Internet Explorer设置的URL长度限制为2,048个字符，因此您希望将POST用于长请求。

http://carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post/

REST - 复杂的应用程序

5 个答案: