web-dev-qa-db-ja.com

POSTでJSONを使用するWebサービスをRESTfulとして分類できますか？

最近、私は新しい（私にとって）パラダイムをWebサービスに使用し始めました。コントローラを使用して、POST経由で送信されたJSON文字列を受け入れ、それを処理してJSON文字列を返します。 GET、PUT、DELETEなどのメソッドはHTTP 405をスローします。

このパターンは、非同期Webフレームワーク（vert.xとplayは特に）の観点からも、開発努力の観点からも非常に効率的であることが証明されています。

私が混乱しているのは、これがSOAPでもRESTでもないようです。JSON-RPCでさえないと思います。自分のヘッダーを次のように使用しているためです。

リクエスト：

{
  'requestId':<generated req Id>,
  'token':<previously authenticated token>,
  'action':<controller defined action>,
  'parameters':[
    <array of parameters>
  ]

}

応答：

{
  'result':'success/fail',
  'payload':{
     <payload>
   }
}

編集： https://my.domain.com/api のようなエンドポイントURLは1つだけです

このパラダイムが何に分類できるかについて誰かが何かアイデアを与えることはできますか？

web-servicesrestjsonsoap
6
Jit B

RESTには実際に2つの定義があります。

  1. Representational State Transfer （ "REST"）as a principal for service design（必ずしもweb service！ではありません）。これは、サーバーがクライアントコンテキストを格納しない均一なクライアント/サーバーインターフェイスを示唆します。 「クライアントは最後にこのページにアクセスしました」。一般的な原則として、RESTfulサービスは特定のリソースを要求する必要があります。記事、または「注文」オブジェクト-およびそのリソースに対して実行するアクション-「取得」、「タグ」、「黄色に塗る」、または必要なものすべて（異なるタイプの同じアクションである限り）リソースの同じ名前を取得します。これらの原則に従えば、HTTPを使用していなくてもWebサービスをRESTfulにすることができます。プロトコルでリクエストされている特定のリソースが表示されない 、しかし再び、それはURLによって定義されるかもしれません。 編集：アクションとは関係なくリソースを指定していないため、この定義ではサービスはRESTfulではありません。

  2. キャリアプロトコルとしてHTTPを使用し、GET、POST、DELETEなどのHTTPリクエストタイプを使用して、実行する必要があるアクションのタイプを指定する特定のリクエストフォーマットとしてのREST。この定義では、サービスは明らかにRESTfulではありません。

プロトコルの最も一般的な説明は、JSONを介したリモートプロシージャコール（RPC）のサービスである可能性がありますが、JSON-RPCではありません。

明確にするために、RESTfulでないことやRESTfulであることには何の問題もありません。あなたのニーズに合うものは何でも。

8
ikh

RESTは、標準のHTTPメソッドの使用とはまったく関係ありません。これは、どのネットワークプロトコルにも等しく適用できる設計概念です。定義するものRESTは、状態の取得と新しい状態の設定のみに制限される操作のセットです。作成と削除はその特殊なケースです。オブジェクトは、未使用のIDを持つオブジェクトの状態を設定することによって作成されます（したがって、クライアントで生成するか、別のクエリで準備する必要があります）、オブジェクトの状態を空に設定して削除します。重要なプロパティは、すべての操作がべき等であることです。つまり、連続して2回実行することは、1回だけ実行することとまったく同じです。

したがって、質問自体は、サービスがRESTかどうかを判断するのに十分な情報を提供しません。しかし、さようならの回答でのコメントは、メソッド「COPY」と「MOVE」について言及しており、これらは適合しませんREST（残りをコピーする唯一の方法は、状態を取得してそれを新しいリソースにアップロードすることであり、移動する唯一の方法は、オリジナルをコピーしてから削除することです）。 RESTはすべての状況に適しています。

2
Jan Hudec

問題は、Yet Another Interfaceを作成していることです。これはRPCに似ています。

[〜＃〜] rpc [〜＃〜] は悪いと言っていません。プログラマにとっては、RPCの方が自然に理解しやすいようです。あなたはおそらくですべてを行うことができますREST RPCで行うことができますが、あなたは考えることに慣れる必要があります関数を呼び出すのではなく、リソースを移動するという用語。

RESTful APIを使用して、レコードを削除したい場合、DELETEリクエストを/ thing/3に送信すると削除されます。取得したい場合は、GETを使用します。それは私が考えたり調べたりする必要がない標準です。

RESTの良い点の1つは、ブラウザを使用してAPIを確認し、データを取得してそれがどのように見えるかを確認できることです。あなたのAPIではできません。

あなたの場合、actionパラメータに何を入れるかを知る必要があります。多分私は単語DELETEを入れました、しかし私はそれを調べなければなりません。

RESTでは、404はレコードが存在しないことを意味します。あなたのもので、私は成功パラメーターを見て、次にいくつかのエラーコードを調べる必要があります。

すでに存在するのに、なぜもう1つのインターフェースを作成するのですか？

1
Neil McGuigan