Yii中的RESTful服务器设计

时间:2011-06-21 15:29:52

标签: php rest yii

嗨,我一直在网上搜寻尽可能多的信息,我可以得到关于在Yii框架中创建一个安静的服务器。

到目前为止我找到的所有示例都涉及编写一个处理一个模型的静态应用程序(IE主题或帖子)

我的问题的症结在于,我应该如何处理编写一个处理大量模型类型的休息服务器,即客户,品牌,项目,任务?

例如,每个Model对象都需要实现CRUD操作 要创建新品牌,系统需要客户端ID,其他CRUD操作也需要。

每个模型对象是否应该有自己的RESTFUl服务器,或者应该有哪种控制器将RESTFUL请求路由到模型对象的相应Rest控制器? 是否应该有一个服务器动态决定使用什么型号的交换机(个人不热衷于这个想法)

任何关于如何实现这种休息架构的建议都会非常棒

我认为值得注意的是,我正在构建的服务器将使用前端的sproutcore,并且只返回JSON,因此不需要任何类型的格式检测。

3 个答案:

答案 0 :(得分:10)

我正在开发Yii中的RESTful应用程序。到目前为止一切都很好。

  • 模型。我有两种型号:

    1. 通过REST接口管理(即创建/删除等)。我打电话给他们resources并将其放入单独的目录中,但从技术上讲,他们是扩展CActiveRecord的模型。
    2. 应用程序使用但未暴露于世界的内部模型。此外,还扩展了其他模型或资源的抽象模型类。
    3. 资源实例可以由REST客户端发送的XML表示构造,并且可以转换为XML表示。您可以定义一个基类AbstractResource来处理这个问题,并在必要时覆盖子资源中的构造/转换方法。

    4. 一个资源有一个控制器。控制器通常有四个CRUD操作,可能还有List操作。后者用于搜索操作。使用基于类的操作而不是内联操作是个好主意,因此您可以在不同的控制器中重用您的操作。例如,我的所有控制器都使用ListAction进行搜索。

    5. 我有基本控制器,它将所有内容发送为application/xml。它还处理HTTP状态代码和handles all errors

    6. 使用Relax NG schemes验证来自客户端的所有XML输入。你需要json验证器。

    7. TDD摇滚!我已经对几乎所有东西进行了广泛测试。在进行重构时它会有很大帮助。使用TDD。为所有模型,资源和应用程序组件编写单元测试。此外,编写功能测试更容易,因为您没有HTML / CSS /等。您只需发送HTTP请求并检查返回的标头,代码和内容。我使用php_curl扩展,它工作得很好。由于您可能会执行PUT,DELETE和其他异常请求,因此您必须手动编写每个HTTP请求。在我的情况下,每个请求也需要签名(这涉及计算校验和,哈希等),因此几乎不可能手动测试我的应用程序。

我也推荐这本优秀的书:RESTful Web Services

答案 1 :(得分:2)

运行此tutorial。只需复制控制器操作即可。编辑第二组操作以与新模型交互。例如,本教程要求在控制器中创建以下操作:

public function actionList()
{
}
public function actionView()
{
}
public function actionCreate()
{
}
public function actionUpdate()
{
}
public function actionDelete()
{
}

您可以为第二个模型创建备用操作。类似的东西:

public function actionListB()
{
}
public function actionViewB()
{
}
public function actionCreateB()
{
}
public function actionUpdateB()
{
}
public function actionDeleteB()
{
}

如果您需要更多信息或说明,请发表评论。祝你好运。

答案 2 :(得分:2)

我正在与我的项目进行类似的练习。

我正在尝试以优雅,可扩展的方式决定使其全部工作的最佳方式。 那就是我所拥有的:

/controllers/apiController
/controllers/api/v1/resourceaController <extends apiController>
/controllers/api/v1/resourcebController <extends apiController>
/controllers/api/v1/resourcecController <extends apiController>

我正在构建的解决方案具有URL规则,根据使用的方法将用户直接重定向到apiController中的相应CRUD函数:

// REST API routes
array('api/list', 'pattern' => 'api/v<version:\d+>/<resource:\w+>', 'verb'=>'GET'),
array('api/create', 'pattern' => 'api/v<version:\d+>/<resource:\w+>', 'verb'=>'POST'),
array('api/view', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>', 'verb'=>'GET'),
array('api/update', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>', 'verb'=>'PUT'),
array('api/delete', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>', 'verb'=>'DELETE'),
array('api/list', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>', 'verb'=>'GET'),
array('api/create', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>', 'verb'=>'POST'),
array('api/view', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>/<association_id:\d+>', 'verb'=>'GET'),
array('api/update', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>/<association_id:\d+>', 'verb'=>'PUT'),
array('api/delete', 'pattern' => 'api/v<version:\d+>/<resource:\w+>/<resource_id:\d+>/<association:\w+>/<association_id:\d+>', 'verb'=>'DELETE'),

接收调用的函数将尝试基于$ _GET ['resource']实例化资源控制器,并调用存储在$ _GET ['association']中的函数。

我认为这可以很好地扩展,因为我们可以推出新版本的API,我们必须创建类似/ api / v2,/ api / v2并放入所有必需的资源控制器在那里。

相关问题