4

RESTful API の範囲と制限を理解しようとしています。具体的な質問は次のとおりです: リソースではなく操作を公開する API を REST で処理するにはどうすればよいですか? 操作を公開する誘惑をあきらめて、API を再考してデータ (リソース) を公開する必要があります。オブジェクトのカプセル化の露骨な違反のように感じるOOPから来ています。

送金を行う REST API を公開する必要があるとします。ある口座から別の口座に金額を送金します。REST を理解していれば、2 つのアカウントをリソースとして公開し、これら 2 つのリソースに対して 2 つの異なる UPDATE 操作を呼び出す必要があります。私には、これはデータのカプセル化に対する明らかな違反のように感じます。私の傾向は、リソース「口座」ではなく、操作「送金」をモデル化する API を作成することです。「データ転送」を行う REST API を作成できますか? それはもはやRESTではありませんか（リソース中心ではないように見えるため）。

RPC 呼び出しが REST よりも適切に見えるこのシナリオについて何かコメントはありますか?

ありがとう

4

2 に答える 2

5

Transfer はそれ自体がリソースであり、独自のライフサイクルを持っていると私は主張します。転送リソースを PUT して、(ビジネス用語で) 転送を開始できます。transfer リソースはアカウント リソースを参照します。他のリソースを参照するリソースは RESTful です。

transfer リソースを取得して、その状態を判断できます。

たとえば、一部の情報が不完全な場合は、リソースへの更新を POST することもできます。

于 2013-09-05T05:12:42.460 に答える
1

それは本当にあなたの好みに依存します。API を純粋な REST の方法で定義するか、寛大にするかはあなた次第です。

REST は、保守を容易にするために API を定義する方法を標準化しました。

たとえば、SOAP の時代にアカウントを作成/変更/削除する必要がある場合、 createAcctのような 3 つの異なる API 定義が存在します。updateAccount、deleteAccount。

RESTでは、 /accounts/を 1 つだけ定義する必要があり、 GET、PUT、POST、およびDELTE HTTP メソッドが対応するアクションを実行すると想定されます。

あなたのケースであなたの質問に答えるために、APIは2つの方法で定義できます

1) - /accounts/1234/transfer/またはリクエストの一部として json 本文 *{to_account:1212,amount:1221}* を投稿します。これは純粋な REST の方法ではありません

. アクションを API の一部として定義しているためです。

2) - /accounts/1234/transactions - post json body *{type:transfer, to_account:1212, amount:1212}*- トランザクションはシステムで作成する新しいリソースの一種であるため、これは PURE REST の方法です。

そこにある多くの残りのAPIには、純粋なRESTの方法からの例外があります。その例の 1 つが「resetpassword」です。一般的な理解が得られるように、firebug を使用していくつかの API をハックしてみてください。

于 2013-09-05T05:19:55.363 に答える