13

私たちは、ほとんどの I/O が特定の構造を持つ JSON でエンコードされたオブジェクトである、かなり複雑な REST API を設計しています。私たちが見つけた課題の 1 つは、クライアントが正しい入力を投稿して出力を処理しやすくするような方法で API を文書化することです。入力と出力の両方のデータがかなり複雑な JSON オブジェクトを必要とするため、クライアント開発者は I/O オブジェクトの構造に関連するバグをしばしば導入します。

最近のすべての JSON Web API で、一般的な解決策を望んでいましたが、見つけるのに苦労しています。json-validation スキーマであるjson-schemaを調べましたが、IETF ドラフトと実装の両方がかなり未熟なようです (しばらく前から存在していましたが、これは良い兆候ではありません)。

Protocol BuffersとApache Avroによって提供されるわずかに異なるアプローチでは、スキーマは検証には使用されませんが、実際にはメッセージのエンコード/デコードに必要です。これら 2 つのうち、Avro のドキュメントと実装はかなり限られているようです。ProtoBuf の方が優れているようですが、ブラウザで JSON API を呼び出すのにこれが本当に適しているかどうかはわかりません。

今、私はこれを正しい角度から見ているのか疑問に思い始めています. 私の API をもう少し強い型付けにするために利用できる他の方法はありますか? それとも、JSON REST/RPC API の正式な記述は、JSON を使用する目的を無効にするものですか?

編集: このトピックの 6 か月後、探していたものに非常に近い mongooseを見つけました。

4

4 に答える 4

8

以下は、Douglas Crockford からメールで受け取った返信です。

私は、入力検証の代わりとしてのスキーマを信じていません。構文から確認できないプロパティがあります。それが XML がうまくいかなかった原因の 1 つだと思います。

フォーマットが複雑すぎる場合は、単純化することを検討します。

于 2012-06-01T02:55:40.807 に答える
4

そのようなシステムが存在し、私はそれらの1つの作者です。これはPiqi-RPCと呼ばれ、HTTPを介したRPCスタイルのAPIの入力パラメーターと出力パラメーターのIDLベースの検証を行います。

HTTP POSTリクエストの入力と出力のデータ表現形式として、JSON、XML、およびGoogleプロトコルバッファをサポートします。クライアントは、3つの形式のいずれかを使用することを選択し、標準ヘッダーAcceptとContent-TypeHTTPヘッダーを使用して選択を指定できます。

ですから、そうです、理論的には、あなたは正しい方向を見ています。ただし、現時点では、Piqi-RPCはErlangでのみサーバーの書き込みをサポートしており、別のスタックを使用する場合はあまり役に立ちません。ApacheThriftはJSONoverHTTPトランスポートもサポートしていると聞きましたが、確認していません。私が知っている別の種類の同様のシステム（Erlangの場合も）はUBFと呼ばれます。Protocol Buffers仕様に基づいてJSONを解析および検証できるJava用のライブラリについて聞いたことがあります（例：http ：//code.google.com/p/protostuff/ ）。

アイデア自体は決して新しいものではありませんが、実際にそれにアプローチするシステムは多くありません。それは挑戦的な問題です。

歴史的に、IDLはインターフェイス定義とバイナリデータのシリアル化に使用されていましたが、後で登場した動的データ交換形式（XMLやJSONなど）の検証にはあまり使用されていませんでした。Sun-RPCIDLとCORBAIDLは最初のカテゴリに分類されます。WSDLは両方の領域をカバーする数少ない例の1つですが、それはひどいテクノロジーであり、ほとんどの最新のシステムにとっては悪い選択です。さらに、多くのスキーマ言語（DDLとも呼ばれます-データ定義言語）があり、そのほとんどは高度に専門化されており、XMLやJSONスキーマなどの1つの表現形式でのみ機能します。それらのいくつかは安定した実装を持っています。

Piqiプロジェクトとそれに基づくPiqi-RPCは、いくつかの非常に単純な実現を中心に構築されています。

  • DLLは、特定のデータ表現形式に明示的に関連付けたり、それを中心に構築したりする必要はありません。代わりに、そのような言語はかなり普遍的であり、幅広い実用的なユースケース（言語間のデータシリアル化やデータ検証など）とデータ形式（JSON、XML、プロトコルバッファなど）をカバーできます。

  • RPCスタイルの通信用のIDLは、ユニバーサルDDLの上に、ほとんど構文上の薄いレイヤーとして実装できます。

  • このようなIDLおよびインターフェイスの仕様は、トランスポートに依存しない場合があります。

HTTPを介したRPCスタイルのAPIと比較したHTTPを介したRESTスタイルのAPIと言えば。

RPCスタイルのAPIを使用する場合、サービス開発者または自動システムは、関数名（サービスの命名スキームによる）、入力、および必要に応じて出力の3つを検証する必要があります。

RESTスタイルのAPIの場合、人々は正当な理由もなく問題を抱えています。今では、検証するものがたくさんあります。URLセグメントにエンコードされた動的パラメーター（すべてのHTTPメソッドの場合）やURLクエリ文字列（HTTP GETメソッドの場合のみ）、HTTPメソッドの対応（GETにする必要があるかどうか）など、任意に複雑なURL構文です。 、POST、PUT、DELETEなど）、一部のパラメーターがそこにある場合のHTTP本文（JSONおよびXMLで表されるパラメーターに対して手動で2回実行する場合もあります）、カスタムHTTPヘッダー、および個別に-サービスドキュメント。それらすべてをサポートするIDLを想像してみてください！

于 2012-06-04T06:40:44.590 に答える
2

XML は、多くの点で RESTful サービスに適しています。ネイティブ リンク ( <link href=、すべてのHATEOASファン向け)、ネイティブ言語サポート ( lang="en")、優れたエコシステムがあります。

また、将来の校正と将来の API リファクタリングにも適しています。これを変換する：

<profile>
    <username>alganet</username>
</profile>

より多くのユーザー名をサポートするには:

<profile>
    <username>alganet</username>
    <username>alexandre</username>
</profile>

XML を使用すると、既存のクライアントを壊すことなく、はるかに簡単に実行できます。JSONはそれが難しいです。

本当に JSON が必要な場合は、JSON-Schema が最適です。それは未熟ですが、そのケースについては何も知りません。コンシューマーは XML と JSON のどちらかを選択できるので、コンテンツ ネゴシエーションを使用して小さなペイロード (JSON) または RESTful キャンディー (XML) を選択できます。

于 2012-06-01T03:08:07.430 に答える
0

最後の質問への答えはイエスだと思います。JSON の「スキーマ」を制約して文書化する方法が必要な場合、なぜ最初から XML を使用しなかったのでしょうか? 解析はそれほど難しくなく、スキーマを適用できることは大きな利点です。

于 2012-05-30T06:58:50.783 に答える