我发现您的设计存在几个问题。
假设我正在构建一个应用程序,让每个人都可以查询一个资源被点击了多少次,以及它的页面被浏览了多少次
唔。这真的不是一个好的 REST 设计。您不能让客户查询选择资源的“属性”,只能查询资源本身。如果您的资源是“页面”,那么 GET 请求/pages/some_page_name
应返回如下内容(在 JSON 中):
{
'url': 'http://example.com/api/pages/some_page_name',
'clicks': 35,
'page_views': 102,
<any other properties of a page resource here>
}
它还让人们在 javascript 中更新资源,说资源被再次点击
“点击某物”是一个动作,所以它不是一个好的 REST 模型。我对您的项目了解不够,所以我可能是错的,但我认为最好的解决方案是让用户单击该事物,然后服务器将收到某种请求(可能是获取资源的 GET被点击了?)。然后,服务器可以clicks
自行增加资源的属性。
(未经身份验证,因为它来自前端)。
这可能很危险。如果您允许任何人更改您的资源,那么您很容易受到攻击,这可能是个问题。没有什么能阻止我查看您的 Javascript 并对您的 API 进行逆向工程,然后发送虚假请求以人为地更改计数器。这可能是可接受的风险,但请确保您了解这可能会发生。
它还让经过身份验证的后端增加页面被查看的次数。
后端?这是客户端还是服务器?听起来应该是客户。再一次,“递增”不适合 REST 类型的 API。让服务器根据从客户端收到的请求来管理计数器。
假设我明白你在说什么,在我看来你只需要支持GET
。服务器可以在收到请求时自行更新这些计数器,客户端不需要为此烦恼。
更新:在下面的评论中提供了一些额外的信息之后,我认为你可以做的是 RESTful 也实现一个PUT
请求(或者PATCH
如果你是部分资源更新)。
如果您执行 a PUT
,则客户端将发送与上述相同的 JSON 表示,但它将增加相应的计数器。您可以在服务器中添加验证以确保计数器按顺序递增,如果发现不是,则返回 400 状态代码(对于某些经过身份验证的用户,可能会跳过此验证,取决于您)。例如,从上面的例子开始,如果您需要增加点击次数(而不是页面浏览量),那么发送一个PUT
请求:
{
'url': 'http://example.com/api/pages/some_page_name',
'clicks': 36,
'page_views': 102
}
如果您正在使用PATCH
,那么您可以删除不更改的项目:
{
'clicks': 36
}
老实说,我觉得这不是解决您问题的最佳设计。您在这里有非常特定的客户端和服务器,它们旨在相互协作。REST 对于解耦的客户端和服务器来说是一个很好的设计,但是如果你站在这条线的两边,那么 REST 并不能真正给你很多。
现在关于您的身份验证问题,如果您的PUT
/PATCH
需要选择性地进行身份验证,那么您可以仅在必要时发出 HTTP Basic 身份验证交换。我写了Flask-HTTPAuth扩展,你可以看看我是如何实现这个交换的,并将代码复制到你的视图函数中,这样你就可以在必要时发出它。我希望这能澄清一些事情。