複雑なAPIと単純なAPIエンドポイント

Question

主にAPIエンドポイントであるバックエンドRailsアプリケーションと、主にReactで構築されているフロントエンドアプリケーションがあります。

は、次のモデルを考えてみましょう：

1. パネル：ダッシュボード内のコンテナ要素です。これは、ダッシュボード内の寸法/位置を定義します。また、content_typeとcontent_id（多態的な関連付け）を使用してコンテンツを定義します。
2. チャート/シングルバリュー/セクション：これらはすべて、パネルのコンテンツとして使用できるモデルです。

ここで私がしたいのは、ユーザーが1つのステップで「チャートパネル」を作成させることです。それが優れている場合、私はここしばらくの間、思ってきた

：

1. は、すべての基本的なCRUDのAPIエンドポイントを持っており、フロントエンドにパネル+チャートの作成に100％を管理します。これは、フロントエンドではより複雑ですが、APIのエンドポイントは少なくなります。
2. パネル+チャート/パネル+シングル_値/パネル+セクション（アトミック操作）を作成するために、Rails側に追加のAPIエンドポイントがあります。これは、フロントエンドの複雑さがはるかに少ないことを意味しますが、より多くのAPIエンドポイントを意味します。

理想的なアプローチは何ですか？

Answer 1

たぶん、各パネルは、（すべてのパネルがコンテンツを必要としていることを考えると）、次のリクエストボディを作成するための/panels/に単一POSTのリクエストを実行します。

{ 
    dimensions: '', 
    positions: '', 
    content: { 
    type: 'chart', // singleValue, section 
    // content attributes 
    } 
} 

私の提案はPanel集中コンポーネントでなければならないことである（これは寸法と位置を解析します）、それぞれchildrenの場合はcontent.typeに従ってレンダリングします。単一のエンドポイントを使用してRESTFul標準を維持することができます。

Answer 2

私の考えでは、UIの複雑さが緩和されれば、細かいエンドポイントを集約してより多くのエンドポイントを作成できます。これは基本的にファサードパターン（https://en.wikipedia.org/wiki/Facade_pattern）です。詳細なエンドポイントに細かいエンドポイントを集約し、UIが前記構造の実装の詳細に入ることなく、より複雑な構造を作成するのに役立ちます。