我们正在使用FOS Rest软件包,起初,我们并不知道正文监听器是活动的。
与此同时,我们创建了许多以JSON格式通过正文接收数据的资源。目前我们只支持JSON格式。现在控制器中的很多都是从Symfony ParameterBag中检索参数,因为身体监听器正在那里注入它们。
那么,您认为让身体监听者承担责任并且在控制器中通过参数包检索参数是一种好习惯吗?这样,无论是通过GET,POST还是正文,所有参数都通过参数包传递给控制器。
我们正在考虑这个因为我们的一些API客户端在没有在标题中提供内容类型的情况下发出请求,因此,正文监听器没有在正文包中注入正文。所以在控制器中我们没有可用的参数。
提前致谢!
答案 0 :(得分:0)
一般而言,API设计最重要的一个方面应该是实现的一致性,以便您的消费者了解如何与您的系统进行交互。为此,我会遵循这种模式:
Content-type: application/json
标头,则向消费者报告他们正在发出非法请求(可以通过设置_format
要求来完成路线;见advanced routing example)如果您必须支持未传递标头的这些旧用户,您可以在kernel.request
事件上创建一个具有非常高优先级的侦听器,该侦听器只检查检测到的mime类型,以及是否它缺少,做这样的事情:
if ($request->getRequestFormat() != 'json') {
json_decode($request->getContent());
if (json_last_error() == JSON_ERROR_NONE) {
$request->setRequestFormat('json');
}
}
(json_last_error()
的使用并不完美;有关更详细的讨论,请参阅this question。)
最后,如果您还没有,请确保您将API控制器限制为正确的请求方法,再次确保它们正确使用并进行开发和使用更多是一致的。例如,如果您正在使用注释,这就像使用FOSRestBundle提供的@Get
,@Post
等代替通常的@Route
一样简单。如果您使用的是YML或XML配置,则它是methods
属性。
虽然单个控制器当然可以通过GET
(带有请求参数),POST
(通过URL编码的表单数据)或POST
接受数据或PUT
使用JSON数据和正文监听器转换,这使得一个非常复杂的API,因为你必须开始维护这些不同的情况,我认为对你的用户而言也变得非常困难。< / p>
作为这些API的使用者,如果我在请求正文中传递JSON但不包括正确的标头,我希望我的请求失败,如果我通过x-www-form-urlencode
,我希望我的请求失败数据到基于JSON的API。总的来说,无论是对于API的维护者还是对于消费者来说,最好严格遵守您所接受的内容,并始终遵循相同的模式。