1

私はRESTAPIを介してチェックアウト/チェックインシステムを表現する問題に取り組んできました。

小さな例を挙げると、システムはノードを処理し、1人のユーザーがこのノードをロックし、変更を加えてからコミットできるようにする方法が必要です。

だから私は次のようなことを考えていました

  • /nodeId（これはノードのベースロケーションであり、ノードのリビジョン読み取り専用ビューでチェックインされた最新のものを提供します）
  • /nodeId/edited（ここに投稿すると、ドキュメントの編集バージョンが作成されます。これはチェックアウトです。取得すると編集バージョンが取得され、配置すると変更が加えられます）

ここで、チェックインを表現したいと思います。POSTを/nodeId/edited再度実行すると、編集されたドキュメントがコミットされますが、投稿には2つの異なる意味があります。別のチェックインエンドポイントを作成することもできますが、それは面倒に思えますか？別の方法は、編集されたバージョンを作成する/ nodeIdへのPOSTを使用することですが、これも混乱しているようです。

4

1 に答える 1

2

To lock/checkout a Resource, POST to /nodeId with the partial document {"locked":"true"}. The server must handle Resource state and check if the Resource can be locked etc. The server could answer 204 No Content if the lock suceeded and 409 Conflict if the lock was not possible.

ロックされたリソースのロックを解除/チェックインするPOSTに/nodeIdは、部分的なドキュメントを使用します{"locked":"false", "someKey":"someValue", ...}。サーバーはリソースの状態を処理し、リソースがロックされているかどうかを確認し、POSTed データを使用してリソースを更新する必要があります。繰り返しますが、サーバーは204 No Content、ロック解除が成功した場合と409 Conflictそうでない場合に応答できます。

編集：可能なHTTPステータスコードを追加しました。

編集 2: SOAP のような REST には「エンドポイント」はありません。メソッドを呼び出すのではなく、リソースを操作します。

于 2012-09-07T10:42:08.463 に答える