Question

我刚刚开始使用REST，并开始按照此设计模型构建我的第一个应用程序。从我可以收集到的想法是建立您的服务，就像您的网站本身是消费者的api。

这对我来说很有意义，因为我的网络应用程序会执行大量的AJAX调用，但是对每个请求进行身份验证以避免使用会话似乎有点浪费。作为REST设计过程的一部分，这是我必须接受的吗？

此外，使ajax调用工作正常，但是，我需要显示用户配置文件的视图，这现在意味着我还需要对我的api进行curl调用以获取此数据。在这一点上，我知道我在内部工作，所以甚至需要验证？

Answer 1

一些评论：

虽然您可以将整个应用程序设置为具有REST 界面，但您应该将其设置为仍然可以在内部调用它。从HTTP调用它，并通过HTTP获取结果只是输入处理和输出渲染。所以，如果你分开这些问题，你就得到了一个流程：input-processing -> method call -> data return -> data rendering。剃须的第一个＆amp;最后一点，你还剩下什么？一个返回数据的函数调用，您可以在代码中使用它。单独的功能将“外部”函数调用转换为“内部”函数，并将“内部”数据呈现为“外部”（xml，json，html，无论您想要什么），使您的应用程序高效，并且仍然完全支持REST。

如果您允许外部呼叫，则需要进行身份验证，即使您没有“告诉”其他用户可以通过某种方式检索数据，它仍然很容易被发现。我不知道为什么您不希望使用会话进行此身份验证（这很可能发生在前面提到的从“外部”调用到内部调用的转换中。我不会让'不使用会话是一项要求，但没有理由不允许多种身份验证方法（会话，对每个请求重新进行身份验证，令牌等）。

Answer 2

通常我更喜欢生成一个可以使用标准PHP调用的接口，然后添加一个接口来添加身份验证和RESTful访问。所以你可以访问例如：

http://example/api/fetchAllFromUsers?auth-key=XXXXX

转换为：

$internalInterface = new Api();
$internalInterface->fetchAllFromUsers();

Answer 3

不是每次都进行身份验证，而是保存一个标识会话的状态块（例如cookie）并使用它。然后它成为GET的参数（使用?name-value语法）或者可以是URI本身的一部分，例如

 http://example.com/application/account/ACCTNO/TOKEN

其中ACCTNO和TOKEN分别标识帐户和真实会话。

这一开始可能看起来有点不稳定，但这意味着随着应用程序变大，您的应用程序永远不需要复杂的会话状态负载平衡等等 - 一个简单的代理方案可以正常工作。这大大增加了架构的复杂性。

设置RESTful Web服务

3 个答案: