アプリケーション用のRESTAPIを計画しており、REST機能用に個別のコントローラーを実装する必要があるかどうかを判断しようとしています。
現在のコントローラーでwithFormat{}を使用することもできますが、異なるコントローラーでREST機能を分離することはややクリーンに感じられます。
このようにして、現在のコントローラーとは別にAPIを構築でき、RESTコントローラーを別のアプリケーションなどに取り込むこともできます。
このテーマについて何か考えはありますか？ベストプラクティスとなる実際の経験はありますか？
最近、同じ決定に直面し、RESTAPI用に個別のコントローラーを使用することにしました。
個別のコントローラーの利点には、よりクリーンで明確なコントローラーアクションと、後で異なるバージョンのRESTAPIをサポートできる可能性があります。
また、個別のサーバーインスタンスでRESTAPIをホストするオプションを開いたままにしておきたいと思います。これらのサーバーはまったく同じ.warを使用しますが、フィーチャートグルの構成設定が異なります。
個別のコントローラーの欠点は、コントローラーコードの乾燥性である可能性があります。これは制限する必要がありますが、IMHOなので、コントローラーをできるだけ薄くし、共有ロジックをGrailsサービスまたはヘルパークラスに抽出する必要があります。
私はすぐにグライルを扱いますが、今のところ私はそれについてほとんど経験がありません。しかし、私が働いていたWebアプリでは、常にWebサービスをコントローラーコードから分離したままにしました。また、RESTをSOAPから分離しました。それらの一般的な方法は、サービス層にあります。確かに、それはよりきれいに感じました。ifメソッドに多くのsを挿入する必要はありませんでした
特定のリソースに対して、コンテキスト（受信または要求されたメディアタイプ-SOAP、JSON、XMLなど）に基づいてサービスレイヤーとインターフェイスする1つのコントローラーを使用します。これにより、真に統一されたリソースIDが得られます。さまざまなメディアタイプを受け入れて返すと、コントローラーは、ユーザーがどのリソースでどのメディアタイプを実行したいのかを知る必要があります。
たとえば、サービスレイヤーは、「toXml」、「toSoap」、「toJson」などのメソッドを持つオブジェクトを返す場合があります。次に、サービスレイヤーに何でもするように要求し、要求されたメディアタイプでswitchステートメントを使用して、要求された情報を返すか、デフォルトで406NotAcceptableステータスコードをスローします。安全でないまたはべき等のトランザクションの場合、オブジェクトには特定のメディアタイプのコンストラクターまたはファクトリメソッドが含まれている可能性があります。その後、サービスレイヤーにそのオブジェクトで何でもするように要求します。