複雑な科学的モデルとインターフェースをとるためのSOAPサービスはRESTfulなサービスより優れていますか?

私は科学的なモデルを持っていて、それは通常複雑なテキストベースの入力ファイルを提供することによって実行されます。ユーザーが基礎となるモデルをインスタンス化できるように、サービスのエンドポイントを提供したいと思います。私ができる最も簡単なことは、ユーザーがテキストベースの入力ファイルをサービスにPOSTできるようにするRESTfulサービスを作成することです。ただし、その入力ファイル形式をエンドユーザーから隠して代わりにAPIを設計したい場合は、RESTまたはSOAPを使用する方が良いでしょうか。この質問をより具体的にするために、私が入力ファイルで話している複雑さのタイプの例を私に提供させてください。

  • 特定のモデルを実行するには、ユーザーは1つ以上の「センサー」を提供する必要があります。
  • 各 "センサー"は、緯度(浮動小数点)、経度(浮動小数点)、センサータイプ(列挙型)を必要とするデータ型として扱うことができます。

SOAPを使用して、以下を定義するXSDスキーマを定義できます。

  • 緯度(フロート)、経度(フロート)、およびセンサータイプを必要とする「センサー」タイプ。
  • 適切な文字列をオプションとして持つENUMの「sensor_type」データ型。
  • 1つ以上の「センサー」タイプを義務付ける「sensor_list」タイプが提供されます。

私の目には、このスキーマは、この複雑さを定義し、後続のWSDLを使用して成功した要求を作成する方法についてユーザーを指導するための優れた方法を表しています。

一方、私はRESTful Webサービス設計の専門家ではありませんが、このレベルの複雑さを適切に表現するのは難しいかもしれません。私が間違っている? SOAPサービスは確かにRESTfulサービスを支持する主流の使用法から脱落しました、しかし私はSOAPサービスがまだ私がレイアウトしたもののようなユースケースのためにもっと理にかなっているかどうか? RESTful API設計による可能性

6
どちらもあなたの目的にはうまくいくと思います。どちらのソリューションでも、ペイロードにXSDスキーマを使用できます。
追加された 著者 JacquesB,
@Ewan:いいえ、XSDはXMLを検証するためのものです。しかし、XMLまたはXSDをSOAPまたはRESTのどちらにも使用できます。 RESTはペイロードにとらわれないので、好みでRESTにJSONを使うこともできますが、それ以外の場合は検証に何かを使わなければなりません。 Json-Schema
追加された 著者 JacquesB,
あなたはXSDに対してJSONを検証することができますか?
追加された 著者 Ewan,

6 答え

私は正直に言ってあなたがどちらかをすることができてそれがちょうどうまく動くようにすることができると思います。 RESTとSOAPに関するインターネット上の投稿はたくさんありますので、ここでは繰り返しません。しかし、私はあなたがどちらかを使うことができることを示したいです。

まず、センサーを表します。 RESTまたはSOAPのどちらでもそのようなことを表現できます。たとえば、XMLで表現したいものはすべてJSONで実行できます。 EX(XML):


  
    your_type
    your_longitude
    your_latitude
  
  
    your_type
    your_longitude
    your_latitude
  
  ...

または(JSON):

{
  "sensors": [
    { "type": "your_type", "latitude": "your_latitude", "longitude": "your_longitude" },
    { "type": "your_type", "latitude": "your_latitude", "longitude": "your_longitude" },
    ...
  ]
}

その後、そのデータをエンドポイントに送信します。 XMLでは、それは最終的にはエンドポイントとメソッドへのPOSTになります( "/MySOAPService.wsdl?method=CreateSensor"などと言います)。これは私のSOAPの錆を許します。 RESTでは、おそらく "/ Sensors"のようなメソッドへのPOSTになります。 SOAPで更新すると、センサーIDがXMLでエンコードされた "/MySOAPService.wsdl?method=UpdateSensor"になります。 RESTは、PUTリクエストでは "/ Sensors/your_id"のようになります(JSON構造はcreateメソッドとupdateメソッドの両方で同じままです)。

いずれにせよ、あなたはそれを機能させることができます。私のいつもの好みは、私の言語がより簡単で、消費者にとって最も使いやすいものは何でもです。

6
追加された

この場合、あなたが使用している多くの用語が多くの方法で過負荷になっているので、最初にいくつかの用語を明確にすることが重要だと思います。これは多大な混乱を招く可能性があります。

ここでは特に、SOAPメッセージフォーマットを参照しているように見えますが、それをサーバーと対話するための標準的な方法であるRESTと比較しています。そして明確にしておきますが、今日使用されているSOAPにはほとんどありません。あなたは基本的にエンベロープ、ボディ、そしてフォルトタイプを取得します。これら3つのXML要素は重要ですか?いいえと主張するでしょう。本当に、あなたはREST対XMLを言っています、それは実際には意味がありません。おそらくXML対JSONを意味しますが、これは意味のある質問です。

つまり、まず第一に、RESTful設計でXMLを完全に100%使用できます。実際、RESTを使用して、XML、SOAP、JSON、Avro、YAMLなどを単一のエンドポイントでサポートできます。これを実現するには、メディアタイプを使用します。実際のところ、SOAPを使用できるのは、SOAP/WSDLを使用している場合だけです。

XMLがJSONより優れているかどうかという質問であれば、文書を作成したくない限り、私は「いいえ」と言います。そのためにXMLが優れているのは、ノード内で混在するコンテンツを許可するためです。つまり、あるテキスト、別の要素(例:その要素内のテキスト)、さらに別のテキストを含めることができます。しかし、ストレートデータの場合は、JSONの方が複雑ではないので一般的に優れています。スキーマが必要な場合は、できます。他にもたくさんあります。上記のように考慮する必要がある形式

サーバーとのやり取りに関しては、RESTがはるかに優れています。 RESTfulな観点から「間違った」ことをしても構わない限り、実際には古いスタイルのSOAP/WSDLサーバーで実行できるRESTサーバーですべてを実行できます。つまり、HTTPの仕様では間違った方法であるにもかかわらず、POSTですべての処理を実行したい場合は、それを実行できます。 SOAP/WSDLについて魔法のようなものは何もありません。ツールがより成熟しているだけでなく、それでもさらに優れているということだけが利点です。 = "nofollow noreferrer">うまく動かない。

3
追加された

すでにご存知のように、SOAP/WSDLは歴史的にプロキシクラスを生成するために使用されていました。これを使用することであらゆるアプリケーションに簡単に接続できます。

このようなプロキシクラスはJavascriptでは必要とされないことは注目に値します。 JavascriptはJSONをネイティブに認識するので、JSONから動的オブジェクトを自動的に作成します。結果のオブジェクトを直接消費するだけです。

同様に、Newtonsoft.Jsonのようなパーサはスキーマが正しく動作することを要求しません。動的変数を使用して実行時にそのメンバをバインドするか、または一致するプロキシクラス(つまりDTO)をコンシューマに提供することができます。

いずれにせよ、もしJSONのWSDLと同等のものが必要なら、 JSONスキーマを検討してください。クライアントは NJsonSchema などのツールを使用してプロキシクラスを生成できます。

0
追加された

そう、XML IS はJSONより優れています。つまり、ドキュメントとしてもデータ構造の検証としても機能する複雑なスキーマを定義できるという点です。

さらに、JavaScriptから来る実際のJSON仕様は、データ型にやや軽いものです。例えば、int、float、decimalなどではなく、 'number'しかありません。大きな数がある場合は、これを伝達できる形式を使用したいことがあります。

しかし3つ目の選択肢があります。それは単に「典型的な」ファイルフォーマットにこだわることです。これが十分に文書化されており、すでに使用されている場合。それから、あなたがポスト変数データを受け入れたならば、それは誰にとっても最も簡単かもしれません:64ビットのエンコードされたファイルデータで

0
追加された

他の答えが示すように、SOAP/XMLとREST/JSONでもほとんど同じことができます。

しかし、現代の言語とフレームワークでは、REST/JSONを実装するのが(サービスプロバイダーとして)、そして消費するのがずっと簡単であることを付け加えたいと思いました。

それで、あなたの消費者に彼らが何を望むかについて尋ねなさい、しかしあなたがそうしないならば、私はRESTが彼らにとってより簡単であると思います。

0
追加された

私はRESTがSOAPよりも現代的で柔軟なアーキテクチャー/アプローチであると思った。理解、使用、拡張、および保守が容易です。

RESTのいくつかの利点:

  • Simple to test/debug, by using HTTP requests with a tool like Postman
  • REST operates with data mainly in JSON format, easier to manage, SOAP is xml based.
  • It allow partial implementation, just needed functions/routines. Using SOAP in most programming languages you should to import whole WSDL. It is "static" and does not support late binding.
  • The same URI in REST can serve all basic data management operations: select/insert/update/delete
  • I meet cases when some SOAP libraries/clients does not pack the data exactly according to SOAP standard/specifications, and there was some incompatibilities between two systems, needed to be integrated.
0
追加された