APIインタフェースの設計:GraphQLとRESTはどのように選択しますか?
記事は専門のLaravel開発者コミュニティから転送され、元のリンク:https://learnku.com/laravel/t...
この話題は開発コミュニティでしばらく議論されていましたが、人々はこれに対して異なる見方と観点を持っています.では、私はどれを使うべきですか.成長が必要だが活力に富んだ新しいメンバーなのか、それとも経験豊富な古いメンバーなのか.その前にRESTとGraphQLについて知っておきましょう.
RESTって何?
RESTは、特定のガイドラインに合致し、Web API実装の制約である記述的状態伝達(英語:Representational State Transfer、略称REST)である.Roy Fielding博士が博士論文で提案したソフトウェアアーキテクチャのスタイルです.クライアントとサーバが無状態モードで情報を交換することを奨励します.すべてのAPIがRESTであるわけではありませんが、すべてのRESTfulサービスはAPIであることを覚えておいてください.
GraphQLって何?
GraphQLは、Web APIのクエリー言語です.Facebookが2012年に作成し、2015年にオープンしました.アーキテクチャモデルでもWebサービスでもありません.様々なデータ・ソースから受信したデータをクエリーする仲介者です.これらのデータソースは、データベースまたはWebサービスであってもよい.
長年、RESTはWeb APIの事実上の基準となっている.標準的なHTTP手法(GET,POST,PUT,DELETEなど)を用いたため、インターネット上のWebアプリケーションの増加に伴い、発展・普及している.また、言語はプラットフォームに関係なく、Webサービスを作成するためのより良い選択になります.各データは、URLを呼び出すときに送信されるリソースとみなされるため、WebブラウザやcURLリクエストを使用して呼び出すこともできます.
RESTの欠点
RESTは非常に成功したが,RESTfulサービスの規模と複雑さが増大しているため,その欠点は非常に明らかになった.
1.マルチエンド(マルチデータインタラクション)
RESTfulサービスのURLは、リソースを表します.したがって、複数のリソースを取得する場合は、複数の異なるURLを要求し、複数回のデータインタラクションをもたらす必要があります.
ブログアプリケーションを考えると1つのブログの下に複数のコメントがある場合.通常、私たちが呼び出すURLは以下の通りです.
私たちが要求するURLがたくさんあることに気づきます.これは、エンティティ(ここではブログとコメントと理解できる)間の関連関係がより複雑になったためです.アプリケーションがますます複雑になるにつれて、これらのAPIの管理もさらに困難になります.
2.過剰取得/取得後のデータ
APIインタフェースを要求すると、不要なデータと関連するデータが取得され、十分なデータが得られない場合があるため、最終的には複数回往復します.これはRESTfulサービスでよくある問題です.場合によっては、2～3個の値しか必要ありませんが、応答として約20～25個の値を得ることができます.これは、応答時間を増加させることによって、未使用のデータを大量に転送するだけです.後者の場合、1つのURLから取得した情報よりも多くの情報を取得する必要がある場合がありますので、複数回の往復が必要です.これにより、クライアントが必要なすべてのデータを取得するのにかかる時間コストが増加します.
3.APIバージョン管理
APIバージョン管理は、応答フォーマットの変更を使用してクライアント・アプリケーションを破壊しないようにする方法です.API応答フォーマットが変更されると、新しいバージョンが作成されます.これは、本番クライアントアプリケーションを予想通りに実行し、開発者に新しいAPIバージョンに移行するための休憩時間を提供するためです.
しかし、このバージョン管理は、新しいバージョンがリリースされると、新しいURLを意味するため、問題です.APIのメンテナンスと使用が困難になり、コードの重複を招くことが多い.
4.弱いタイプ
RESTfulサービスから受信したすべてのデータが強いタイプではありません.すなわち、特定のデータが正しく与えられていません.これは、URLを呼び出してクライアントが望むデータ型を指定する必要があるため、APIを記録する際に問題になります.
5.クライアントはドラムに覆われている
応答構造が受信されるまで、クライアントは応答構造を知らない.だから、クライアントはドラムに隠されています.これにより、いくつかのエラーやデータが正しく処理されず、APIを消費する信頼性が低下することがよくあります.
GraphQLのメリット
GraphQLはFacebookによって発明され、主にRESTの欠点を克服するためである.
1.すべてのリクエストを一度に取得
GraphQLサービスは、クライアントが必要なクエリーを送信してデータを取得できるように、エンドポイントを1つだけ露出します.前述の例を使用して、GraphQLクエリを見てみましょう.
ご覧のように、私たちは単一のリクエストだけで必要なすべてのデータを取得しました.新しいフィールドをクエリーに追加するだけで応答に表示されます
2.強いタイプ
GraphQLは強いタイプのモードによって制御される.これらのタイプは、オリジナルであっても派生であってもよい.強力なタイプのシステムでは、APIがドキュメント化され、クライアントが特定のクエリーをクエリーするときにどのような応答が得られるかを知ることができます.
3.クライアントドライバ
GraphQLは、クライアントが必要なフィールドを正確に指定するための宣言構文を提供します.これにより、クライアントがパターンに従ってGraphQLサーバにデータ要件を宣言することによって、データが冗長で不十分になる可能性が排除されます.
4.APIの進化
GraphQLではすべてモード(schema)駆動であるため、新規フィールドは既存のフィールドに影響を及ぼさず、またGraphQLは廃棄フィールドに
5.伝送層が分からない
これはGraphQLの素晴らしい利点です.APIサーバは,HTTP,HTTPS,WebSockets,TCP,UDPのようなプロトコルで情報交換を行うことができる.これは、GraphQLがクライアントとサーバの間で情報をどのように交換するかに関心を持っていないためです.
GraphQLの欠点
わあ、GraphQLは素晴らしいです.これはよく知られている事実です.しかし、世界のどんなものにも欠陥があり、GraphQLも身を置くことができない.
1.キャッシュ機能が未熟
GraphQLはブラウザと携帯電話のキャッシュをサポートしていません.これは、ローカルHTTPキャッシュメカニズムを使用したRESTfulサービスとは異なり、GraphQLキャッシュの実現にさらに努力します.Relayのようなツールはいくつかのキャッシュサポートを提供していますが、RESTfulサービスで使用されるキャッシュメカニズムはまだ成熟していません.
2.検査とエラー報告
RESTfulサービスは、HTTPステータスコードを利用して、発生する可能性のある異なるエラーを処理する.開発者にとって、APIsの検査は非常に簡単で楽になりました.しかし、GraphQLサービスを使用すると、常に
これにより、エラーシーンの処理が非常に困難になり、検査プロセスが非常に面倒になる.
3.露出モードと資源攻撃
RESTfulサービスとは異なり、GraphQLサービスでは、クライアントがクエリーするデータ・モードを知る必要があります.APIをサードパーティに暴露すると、内部データ構造が基本的に暴露されます.クライアントが高いコストで接続クエリーを開始できないため、サーバ上のサービス拒否(DoS)攻撃を引き起こす可能性があるので、注意してください.
4.セキュリティ-認証と認証
GraphQLコミュニティは、GraphQLサービスのセキュリティ部分をどのように処理するかに困惑しています.認証と認可を統合したオリジナルのソリューションはまだありません.通常、ビジネスロジック層に抽象化されてユーザーを許可しますが、経験のないユーザーのクエリーを解析して検証する必要があるかどうかはGraphQL分野の問題です.
5.N+1次クエリ問題
RESTfulサービスでは、実行されたSQLクエリーを簡単に記録し、さらに最適化できます.しかし,GraphQLの場合,解析的性質は動的であるため,正確なクエリを得てさらに最適化することは困難である.フィールド解析器によっては、N+1クエリの問題と複雑な接続操作が発生する場合があります.しかし、Facebookはこの正確な問題を解決するためにDataLoaderのようなツールを開発しています.だから、未来には不利な要素ではないかもしれません.
6.若い生態
GraphQLはこのAPI生態系では赤ちゃんによく似ています.これは、いつでも問題や破壊的な変更が発生する可能性があることを意味します.そのため、GraphQLに関連するライブラリやモジュールを使用するときは、非常に注意しなければなりません.
まとめ
まずGraphQLは単なるツールであり、RESTはアーキテクチャモデルであると言います.RESTの代わりにGraphQLを使うとすれば、大間違いです.しかし、このマイクロサービスの時代、APIを分離して原子レベルに作成し、銀弾がないため、この2つの側面の優位性を利用することができます.
GraphQLサービスはパフォーマンスを最優先とし、RESTfulサービスは信頼性を維持します.
GraphQLノードは、既存のRESTfulサービスを介してノードとして開示することができ、例えば
いくつかのシーンでは、GraphQLを使用するとより良くなり、RESTがより良いシーンもあります.そのため、どちらが良いかを言う前に、関連する需要とデータを分析してから、どちらが適切かを知る必要があります.
この話題は開発コミュニティでしばらく議論されていましたが、人々はこれに対して異なる見方と観点を持っています.では、私はどれを使うべきですか.成長が必要だが活力に富んだ新しいメンバーなのか、それとも経験豊富な古いメンバーなのか.その前にRESTとGraphQLについて知っておきましょう.
RESTって何?
RESTは、特定のガイドラインに合致し、Web API実装の制約である記述的状態伝達(英語:Representational State Transfer、略称REST)である.Roy Fielding博士が博士論文で提案したソフトウェアアーキテクチャのスタイルです.クライアントとサーバが無状態モードで情報を交換することを奨励します.すべてのAPIがRESTであるわけではありませんが、すべてのRESTfulサービスはAPIであることを覚えておいてください.
GraphQLって何?
GraphQLは、Web APIのクエリー言語です.Facebookが2012年に作成し、2015年にオープンしました.アーキテクチャモデルでもWebサービスでもありません.様々なデータ・ソースから受信したデータをクエリーする仲介者です.これらのデータソースは、データベースまたはWebサービスであってもよい.
長年、RESTはWeb APIの事実上の基準となっている.標準的なHTTP手法(GET,POST,PUT,DELETEなど)を用いたため、インターネット上のWebアプリケーションの増加に伴い、発展・普及している.また、言語はプラットフォームに関係なく、Webサービスを作成するためのより良い選択になります.各データは、URLを呼び出すときに送信されるリソースとみなされるため、WebブラウザやcURLリクエストを使用して呼び出すこともできます.
RESTの欠点
RESTは非常に成功したが,RESTfulサービスの規模と複雑さが増大しているため,その欠点は非常に明らかになった.
1.マルチエンド(マルチデータインタラクション)
RESTfulサービスのURLは、リソースを表します.したがって、複数のリソースを取得する場合は、複数の異なるURLを要求し、複数回のデータインタラクションをもたらす必要があります.
ブログアプリケーションを考えると1つのブログの下に複数のコメントがある場合.通常、私たちが呼び出すURLは以下の通りです.
GET /posts/ -
GET /posts//comments -
GET /posts//comments/ -
私たちが要求するURLがたくさんあることに気づきます.これは、エンティティ(ここではブログとコメントと理解できる)間の関連関係がより複雑になったためです.アプリケーションがますます複雑になるにつれて、これらのAPIの管理もさらに困難になります.
2.過剰取得/取得後のデータ
APIインタフェースを要求すると、不要なデータと関連するデータが取得され、十分なデータが得られない場合があるため、最終的には複数回往復します.これはRESTfulサービスでよくある問題です.場合によっては、2～3個の値しか必要ありませんが、応答として約20～25個の値を得ることができます.これは、応答時間を増加させることによって、未使用のデータを大量に転送するだけです.後者の場合、1つのURLから取得した情報よりも多くの情報を取得する必要がある場合がありますので、複数回の往復が必要です.これにより、クライアントが必要なすべてのデータを取得するのにかかる時間コストが増加します.
3.APIバージョン管理
APIバージョン管理は、応答フォーマットの変更を使用してクライアント・アプリケーションを破壊しないようにする方法です.API応答フォーマットが変更されると、新しいバージョンが作成されます.これは、本番クライアントアプリケーションを予想通りに実行し、開発者に新しいAPIバージョンに移行するための休憩時間を提供するためです.
しかし、このバージョン管理は、新しいバージョンがリリースされると、新しいURLを意味するため、問題です.APIのメンテナンスと使用が困難になり、コードの重複を招くことが多い.
4.弱いタイプ
RESTfulサービスから受信したすべてのデータが強いタイプではありません.すなわち、特定のデータが正しく与えられていません.これは、URLを呼び出してクライアントが望むデータ型を指定する必要があるため、APIを記録する際に問題になります.
5.クライアントはドラムに覆われている
応答構造が受信されるまで、クライアントは応答構造を知らない.だから、クライアントはドラムに隠されています.これにより、いくつかのエラーやデータが正しく処理されず、APIを消費する信頼性が低下することがよくあります.
GraphQLのメリット
GraphQLはFacebookによって発明され、主にRESTの欠点を克服するためである.
1.すべてのリクエストを一度に取得
GraphQLサービスは、クライアントが必要なクエリーを送信してデータを取得できるように、エンドポイントを1つだけ露出します.前述の例を使用して、GraphQLクエリを見てみましょう.
{
findPost(id: ) {
id
title
content
author
comments {
id
comment
commentedBy
}
}
}
ご覧のように、私たちは単一のリクエストだけで必要なすべてのデータを取得しました.新しいフィールドをクエリーに追加するだけで応答に表示されます
2.強いタイプ
GraphQLは強いタイプのモードによって制御される.これらのタイプは、オリジナルであっても派生であってもよい.強力なタイプのシステムでは、APIがドキュメント化され、クライアントが特定のクエリーをクエリーするときにどのような応答が得られるかを知ることができます.
3.クライアントドライバ
GraphQLは、クライアントが必要なフィールドを正確に指定するための宣言構文を提供します.これにより、クライアントがパターンに従ってGraphQLサーバにデータ要件を宣言することによって、データが冗長で不十分になる可能性が排除されます.
4.APIの進化
GraphQLではすべてモード(schema)駆動であるため、新規フィールドは既存のフィールドに影響を及ぼさず、またGraphQLは廃棄フィールドに
@deprecatedの注釈を提供するため、GraphQLの拡張は問題ではない.これにより、APIバージョン管理の必要性が解消されます.5.伝送層が分からない
これはGraphQLの素晴らしい利点です.APIサーバは,HTTP,HTTPS,WebSockets,TCP,UDPのようなプロトコルで情報交換を行うことができる.これは、GraphQLがクライアントとサーバの間で情報をどのように交換するかに関心を持っていないためです.
GraphQLの欠点
わあ、GraphQLは素晴らしいです.これはよく知られている事実です.しかし、世界のどんなものにも欠陥があり、GraphQLも身を置くことができない.
1.キャッシュ機能が未熟
GraphQLはブラウザと携帯電話のキャッシュをサポートしていません.これは、ローカルHTTPキャッシュメカニズムを使用したRESTfulサービスとは異なり、GraphQLキャッシュの実現にさらに努力します.Relayのようなツールはいくつかのキャッシュサポートを提供していますが、RESTfulサービスで使用されるキャッシュメカニズムはまだ成熟していません.
2.検査とエラー報告
RESTfulサービスは、HTTPステータスコードを利用して、発生する可能性のある異なるエラーを処理する.開発者にとって、APIsの検査は非常に簡単で楽になりました.しかし、GraphQLサービスを使用すると、常に
200 OK応答が返されます.典型的なGraphQLエラーメッセージは、200 OKのステータスコードである.{
errors: [
{
message: 'Some error occurred'
}
]
}
これにより、エラーシーンの処理が非常に困難になり、検査プロセスが非常に面倒になる.
3.露出モードと資源攻撃
RESTfulサービスとは異なり、GraphQLサービスでは、クライアントがクエリーするデータ・モードを知る必要があります.APIをサードパーティに暴露すると、内部データ構造が基本的に暴露されます.クライアントが高いコストで接続クエリーを開始できないため、サーバ上のサービス拒否(DoS)攻撃を引き起こす可能性があるので、注意してください.
4.セキュリティ-認証と認証
GraphQLコミュニティは、GraphQLサービスのセキュリティ部分をどのように処理するかに困惑しています.認証と認可を統合したオリジナルのソリューションはまだありません.通常、ビジネスロジック層に抽象化されてユーザーを許可しますが、経験のないユーザーのクエリーを解析して検証する必要があるかどうかはGraphQL分野の問題です.
5.N+1次クエリ問題
RESTfulサービスでは、実行されたSQLクエリーを簡単に記録し、さらに最適化できます.しかし,GraphQLの場合,解析的性質は動的であるため,正確なクエリを得てさらに最適化することは困難である.フィールド解析器によっては、N+1クエリの問題と複雑な接続操作が発生する場合があります.しかし、Facebookはこの正確な問題を解決するためにDataLoaderのようなツールを開発しています.だから、未来には不利な要素ではないかもしれません.
6.若い生態
GraphQLはこのAPI生態系では赤ちゃんによく似ています.これは、いつでも問題や破壊的な変更が発生する可能性があることを意味します.そのため、GraphQLに関連するライブラリやモジュールを使用するときは、非常に注意しなければなりません.
まとめ
まずGraphQLは単なるツールであり、RESTはアーキテクチャモデルであると言います.RESTの代わりにGraphQLを使うとすれば、大間違いです.しかし、このマイクロサービスの時代、APIを分離して原子レベルに作成し、銀弾がないため、この2つの側面の優位性を利用することができます.
GraphQLサービスはパフォーマンスを最優先とし、RESTfulサービスは信頼性を維持します.
GraphQLノードは、既存のRESTfulサービスを介してノードとして開示することができ、例えば
/ graphqlであり、GraphQLクエリを実行するゲートウェイとして機能することができ、また、いくつかのシーンのためにRESTノードを維持することもできる.いくつかのシーンでは、GraphQLを使用するとより良くなり、RESTがより良いシーンもあります.そのため、どちらが良いかを言う前に、関連する需要とデータを分析してから、どちらが適切かを知る必要があります.