2016-10-29 8 views

答えて

2

RESTはGraphQLのような建築スタイルではなく、形式やクエリ言語(あります)です。部分的なリソースやリソースの階層をサポートするAPIを構築することも可能ですが(他の例にはJSONパッチやJSONグラフが含まれます)、そのようなアプローチはRESTの概念の一部ではありません。一方、は、で、GraphQLの概念的な部分です。あなたはGraphQLといくつかの類似点を持つ例を選んだが、これはRESTfulなサービスであるという理由によるものではない。

一方、RESTは、GraphQLに準拠していない(またはその逆の)いくつかのアプローチに基づいています。不完全なリストには以下が含まれます。

  • HTTPはRESTのビルディングブロックです。 GraphQLの仕様は "クライアント"と "サーバー"を表していますが、私はそれを読み取らなかった HTTPが必要です。
  • RESTはHTTP動詞に基づいています。 GraphQLはHTTPを必要としないようですが、HTTP動詞は必要ありません。これはうまくいきません。GraphQLでは、1つのクエリで操作を混在させることができます:1つのリクエストで突然変異+クエリを実行することができます。これはRESTと互換性がないため、クエリはGETでなければならない突然変異はPOSTまたはPUTでなければならない。
  • HTTPステータスコードのセマンティクスがGraphQLにありません。
+0

あなたは絶対に正しいです。たぶん、あなたは2つのことを比較することができますか、しないでください。今のところ、この目的のためにFacebookによって挿入されたので、私はHTTPに関連してGraphQLを見ただけですか? –

+1

私はHTTP以外の何かを見たことがありません。実際には、トランスポートやレスポンスのシリアル化形式(JSONは必須ではなく「推奨」)などの重要なことについて、仕様にルーム(HTTPなどのトランスポートを介して送信されたもの)を残しておくことにかなり驚きました。 GraphQLがユビキタスな言語になることを確実にしたいときには、おそらく意味をなさないでしょう。しかし、私は、多くの人々がRESTfulなサービスが「独自仕様」であり、GraphQLが「オープン」であると思っているように見えますが、仕様のこの格差は独自仕様のトランスポートやシリアライズフォーマットを可能にします。 – BlueM

関連する問題