APIインスタンス内から内部的にAPIエンドポイントを呼び出すのは悪い設計ですか？
コンテキストについては、REST APIはNode.jsで構築されたAPIを実行しています。コールバックといくつかの複雑なDB呼び出しのため、非同期でありながら一意である関数のチェーンがあるため、冗長性を減らす：冗長性を減らすために、コード自体から自分のエンドポイント（異なるエンドポイント）を呼び出すというアイデアを思いつきましたが、これは悪い習慣ですか？
たとえば、私は持っているでしょう：
app.get("/puppies/:id"...) // Simple get by ID endpoint
app.post("/puppies"...) // Simple puppy update, but checks an attribute of puppy first by getting by ID
ポストエンドポイントでは、ポストコード内で単に「get」エンドポイントを呼び出すのはいいことですが、それは汚いと感じます。考え？
実際にHTTPリクエストを行うことはほとんどありません。
基盤となるアプリケーションがサンプルからのGETリクエストを処理するとき、おそらく入力チェックを行うビジネスレイヤーを呼び出し、次に子犬を取得するデータアクセスレイヤーを呼び出します。
同様に、POSTリクエストでは、追加のGETを実行する代わりに、ビジネスレイヤーに子犬を更新するように要求するだけです。ビジネスレイヤーは、データアクセスを呼び出すことから開始します。対応する子犬を取得するレイヤーメソッド。
ただし、追加のHTTPリクエストを実行すると、いくつかの欠点があります。
パフォーマンスコストが発生します。たとえば、入力を2回サニタイズしますが、1回で十分です。 HTTPコンテキストを作成して処理するにはコストもかかります。それほど大きくありませんが、簡単に回避できるのになぜ追加するのでしょうか。
これにより、アプリケーションが本来よりも複雑になります。必要なデータが目の前にあるのに（つまり、データアクセスレイヤーインターフェイスで）HTTP要求を行うのはなぜですか？
そして、私はあなたが必要とするだろうすべての追加のコードについてさえ言及しません。たとえば、呼び出すサービスのURIをどのように構成しますか？それは構成に入れられますか（はいの場合、サービスが移動するとどうなりますか）、またはオンザフライで生成されますか（その場合、適切なソリューションを見つけるのにどれだけ時間がかかりますか？ URI、HTTP/HTTPSなど？）
アプリサーバーログに1行追加されます。そして、リバースプロキシのログ。
コードをリファクタリングするのがより難しくなります。たとえば、ビジネスレイヤーが子犬を取得するデータアクセスレイヤーのメソッドを呼び出すソリューションでは、ロジックをレイヤーの下に移動することを考えるのはごく自然なことです。クエリの形式のデータアクセスレイヤー、またはおそらくデータベース自体です。 。一方、HTTPリクエストを実行すると、GETリクエストの背後にあるロジックが完全に抽象化され、後で最適化することができなくなります。
はい、そのbad（tm）。
おそらく不必要ですが、HTTP呼び出しを行うための余分なオーバーヘッドは、それほど大きな要因にはなりません。
本当の危険は次のとおりです。
エンドレスループの偶発的な導入。つまり、PostコールのgetおよびGetコールのPostまたは同様のシナリオ。
インデントされていないキャッシュ効果
httpサーバーの問題、サーバーでの最大リクエスト数など
スレッドの問題、呼び出しを行って非同期で処理されるのを待つとき
基本的に、コードを壊さないビットとボブがたくさんありますが、心配する必要のない問題が確実に発生します。
いずれの場合も、コードはget呼び出しを簡単に行うことができるように、またはその一部を直接構成する必要があります。 httpレイヤーにヒットすることなく。コードをビジネスレイヤーに配置していないようです
Wordpressは、Rest APIフレームワークで許可されています。 " internal request "と呼ばれ、その目的は（例のように）バッチリクエストを簡単に作成できます。内部リクエストを作成するために使用されるメソッドは、URLではなくRequestオブジェクトを受け入れます。記事を読むだけで、ソリューションでそれをコーディングする方法がわかります。