REST APIをバックエンドから利用するのも悪い選択ですか?

フロントエンドコードにREST APIを使用することは、望ましい一般的なやり方です。
しかし、バックエンドにも使うのが良い選択だろうかと私は思っていました。

データベースから直接データを取得するのではなく、データベースからデータを取得するという負担をすべてAPIに渡してから、バックエンドの他の部分(主にビューとコントローラ)から呼び出すということです。

私が本当に心配していることの1つは、フロントエンドとバックエンドの間でコードを共有することで、APIをデータの共通のソースとして使用することは非常に便利です。

So the question is, are there some reasons which make this a bad idea?

4
これは通常サービス指向アーキテクチャと呼ばれます。
追加された 著者 Philipp,

5 答え

データベースからコンポーネントを分離すること、または直接データベース接続から離れることは一般的なパターンです。ミドルウェア/データベースをフロントエンドするコンポーネントにアクセスを移動すると、セキュリティとモジュール性を向上させることができ、そうでなければSQL、ストアドプロシージャ、およびクライアント側のデータベースコードに "陥る"データ検証と解釈を実装できます。これに対して、そのミドルウェア/データ管理フロントエンドの開発、実行時間、そしておそらく経済的なコストを比較検討する必要があります。しかし、多くのプロジェクト規模では、データのフロントエンドがしばしば良い選択と見なされます。

RESTful APIを使用して - 特にその一般的な形式で、バックエンドの設計とコンポーネントを制御する場合HTTPで提供され、JSONでエンコードされている - 他の方法(例えば直接ライブラリリンク、プロトコルバッファ)と比較して著しく非効率的です。リサイクル、さまざまな種類の ESB 、他のRPCメカニズム、...からテキストへの変換、配信、テキストからのシリアル化解除のサイクルを経ないAPI呼び出しごとに。 RESTは、いくつかの構成要素(例:マルチステップトランザクション、ストリーミング、ラージバイナリオブジェクト、例外の発生、保証された配信など)がより単純に、きれいに、または直接処理されるため、腕の長さのインタラクションメカニズムとして意味的に優れています。他の形の相互作用。

それでも、RESTfulバックエンドを使用したい理由がいくつかあります。単純さ、一貫性(ローカルまたはリモートのすべてのクライアントが1つのAPIしか使用しない)、および製品化までの時間(別のAPI /対話スタイルの習得は不要)これらは、RESTful APIを介して比較的直接的にデータベースを公開していることを前提としています。それが厳密にあなたの管理下にあるコンポーネントの使用のためのものであるならば、RESTはおそらく最良の選択ではありません(意味の豊富さまたは効率性のために)。

5
追加された
これは素晴らしい答えです。 RESTコントローラーを薄くして「要求を解析し、ビジネスモデルクラスのlibを呼び出し、結果を返す」ことのみを担当する場合は、そのライブラリーを直接呼び出すことをお勧めします。あなたのコントローラの中でhttpに関係しないロジックに注意してください。
追加された 著者 RubberDuck,
答えてくれてありがとう!そして、主な関心事の1つは非効率であり、API実装からアクセス層を抽象化する方法を考えているので、REST方式でアクセスすることができますが、コードから直接アクセスできますHTTP
追加された 著者 Henrik,

データアクセスをRESTful APIにすることの正当な理由は、データアクセスが他の環境との関係にあることだと思います。

それについて考えてみてください。APIの力は、通常、それを消費することができる膨大な量の「クライアント」実装者です。それはあなたのケースでも変わらないはずです。

言い換えれば、もしあなたがこの同じデータアクセスの複数のコンシューマや異なるインボーカを持っていたり、それをスケールアウトしようとしているのなら、それは意味があると思います。

しかし、逆に、単一のコンシューマーがいて、このデータアクセスとロジックが非常に具体的に調整されていて規模が拡大しない場合、RESTful APIを介してビットを転送することによって得られるものはわかりません。

3
追加された

必ずしも。ミドルウェアはすべてを扱うことはできません。これを示すために私がいつも持ち出している3つの例があります:バッチ処理、フォワード、そしてapiチェーニング。これらすべては、元のリクエストの範囲内に留まることによって利益を得ますが、アプリケーションでは、多くの場合、プロキシ/ APIゲートを経由して出入りする必要があります。

APIからI/Oを抽象化してインターセプターに移動することで、プリハンドラー/ポストハンドラーを使用して通信をハンドオフし、1つのスレッドを使用してループを処理できます。

APIゲートからアプリケーションインスタンス、レスポンスツーリングまでのI/Oフローは、1つの定まった流れであり、壊れることはありません。

詳細については、APIの抽象化とAPIチェーンを参照してください( http://www.slideshare.net/bobdobbes/api-abstraction-api-chaining

0
追加された
SpringOne、Apple、Amazon、Mashery、Paypalなどの機関で発表を求められることが多いのは、オープンソースの科学研究です。私の所属先は何にしますか?自己:)
追加された 著者 Ian Storm Taylor,
私はあなたが完全に言っていることを理解しています。人々は自己宣伝/伝道に眉をひそめます。しかし、同時に新しいアイデアについての科学的な議論をせずにそれを打ち破ることはできません。あなたは両方の方法に気をつけなければなりません...それは私があなたを聞く少しトリッキーな状況です。
追加された 著者 Ian Storm Taylor,
「ここのコミュニティはあからさまな自己宣伝を投票し、スパムとしてフラグを立てる傾向があります。適切で適切な回答を投稿してください。すべてではないが一部の製品またはWebサイトに関するものであれば、問題はありません。あなたの答えの中の所属。」 (ヘルプセンター>我々のモデル>スパマーにならない方法
追加された 著者 gnat,
追加された 著者 gnat,

バックエンドからREST APIを使用することには2つの利点があります。別のAPIを開発して文書化する必要がなく、1つのバグセットしかなく、2つのバグがあります。

2つの反論があります:あなたのバックエンドが既存のAPIに適合しないことをするのかもしれません(フロントエンドAPIがするように反対方向からデータを見るかもしれないので)。そしてパフォーマンスの問題があるかもしれません:バックエンドがフロントエンドよりも10倍多くデータベースを使用していて、それがパフォーマンス上重要であるなら、最も単純なAPIは望まないが、最速です。

それであなたのバックエンドがデータベースをどのように使用するかを確認し、そこから決定してください。バックエンドがREST APIの機能に満足していて、パフォーマンスの問題がない場合は、REST APIを使用してください。

0
追加された
バックエンドが幸せでも。 dbへのすべてのアクセスを分散コンピューティングの問題にさらすことは価値がありますか?
追加された 著者 glacier,

A lot of good answers and comments. To me, it seems microservice oriented. The challenge is that there is slight overhead inserting a layer between your data access and the backend code that churns on that data. Overhead in terms of development time & cycles, and overhead in terms of code performance. But the upsides are that your application components are more loosely coupled so you can extend/change the code with less complexity. If everything that accesses the data does so through the API, then any changes you need to make to the underlying data model if you make the API handle seamlessly then you are done.

反対に、コードのいくつかの部分がいくつかの場所でデータにアクセスしている場合は、検討し、実行し、テストする必要があります。また、バックエンドコードがデータにアクセスする場所が複数ある場合は、矛盾が生じる傾向があります。

0
追加された