0

私のApigilityプロジェクトには、さまざまなRestリソースがあり、それらはすべてクラスResourseAbstractを拡張し、そこでApigilityのニーズに応じてAbstractResourceListenerを拡張します。

たとえば、私のリソース ユーザー:

<?php
namespace Marketplace\V1\Rest\User;

use ZF\ApiProblem\ApiProblem;
use Marketplace\V1\Abstracts\ResourceAbstract;

class UserResource extends ResourceAbstract
{
    public function fetch($id)
    {
        $result = $this->getUserCollection()->findOne(['id'=>$id]);
        return $result;
    }
}

そして ResourceAbstract:

<?php

namespace Marketplace\V1\Abstracts;

use ZF\Rest\AbstractResourceListener;
use Zend\ServiceManager\ServiceLocatorAwareInterface;
use Zend\ServiceManager\ServiceLocatorInterface;
use ZF\ApiProblem\ApiProblem;

class ResourceAbstract extends AbstractResourceListener implements ServiceLocatorAwareInterface {

}

ここで、http 要求が行われるたびに関数を実行する必要があります。ブラウザーで /user を照会すると、UserResource クラスがインスタンス化されるため、ResourceAbstract を使用して、各呼び出しで何かを実行するための「解決策」を使用することでした。 ResourceAbstract 内のコンストラクターであり、これは「機能します」:

function __construct() {
    $appKey = isset(getallheaders()['X-App-Key']) ? getallheaders()['X-App-Key'] : null;
    $token = isset(getallheaders()['X-Auth-Token']) ? getallheaders()['X-Auth-Token'] : null;
    //some code
    return new ApiProblem(400, 'The request you made was malformed');
}

問題は、場合によっては ApiProblem を返す必要があることです (http 要求のヘッダーが正しくない) が、ご存知のように、コンストラクター関数はパラメーターを返しません。別の解決策は例外をスローすることですが、Apigility では、API に問題がある場合に ApiProblem を使用することになっています。コンストラクターのアプローチは正しいですか? これをどのように解決しますか？

4

2 に答える 2

0

コードの親部分で例外をキャッチする限り、例外をスローすることが解決策になります。

アジリティ プロジェクトで ZEND MVC を使用していますか?

はいの場合は、MVC がディスパッチを行う前に実行される呼び出しを接続することを検討できます。

そのアプローチの実現可能性を調べたい場合は、stackoverflow で尋ねられた質問を確認できます: Zend Framework 2 ディスパッチ イベントは、アクションの前に実行されません。

于 2015-02-28T15:09:59.993 に答える