API を設計し、アドバイスを求めています。
アクションは次のとおりです。
publish
: ドキュメントを公開します (POST)update
: ドキュメントを更新します (PUT または PATCH)unpublish
: 後でアップするつもりでドキュメントを削除します (?)delete
: ドキュメントを完全に削除 (DELETE)
何か案は?
ありがとう!マット
API を設計し、アドバイスを求めています。
アクションは次のとおりです。
publish
: ドキュメントを公開します (POST)update
: ドキュメントを更新します (PUT または PATCH)unpublish
: 後でアップするつもりでドキュメントを削除します (?)delete
: ドキュメントを完全に削除 (DELETE)何か案は?
ありがとう!マット
あなたが持っているように、更新と削除はかなり明白です。
「発行」と「作成」は同じだと思いますか? 「公開」とは、自分が作成した文書を公開して公開することを意味します。1 つの考え方として、ドキュメントを作成できるのは 1 回だけですが、その後は何度でも公開および非公開にすることができます。
ドキュメントのライフサイクルと、「非公開」後に何ができるかについて考えるかもしれません。それは、「作成(公開?)...非公開...公開...非公開...削除」というシーケンスが何をしたいかによって異なります。公開/非公開が作成/削除と変わらない場合は、それらを削除して複雑さを完全に回避できます。
純粋な REST の答えは、{ ... "published": true ... } という表現でプロパティを提供し、クライアントに更新を PUT してその状態を変更させることです。その状態が変化すると、ドキュメントの公開または非公開に必要な処理がトリガーされます。
しかし、ドキュメントを公開することは公的にも技術的にも大きな影響を与える可能性があるため、私はそれを不快に思っていたチームに所属していました。そこで彼らは代わりに、操作を POST の「データ処理」リクエストとして扱い (HTTP 仕様が提供するように)、文書を「公開」および「非公開」するための POST URL を提供することを選択しました。
他にもいくつかのオプションがあります。同様に、追加動詞として POST を使用し、必要な処理を行って、公開リストにドキュメントを追加できる「公開リスト」URI を提供します。
POST ht_p://.../documents {ドキュメント}
POST ht_p://.../published-documents {id=}
削除 ht_p://.../published-documents/{id}
削除 ht_p://.../documents/{id}
編集: stackoverflow が文句を言ったので、prentend URI を壊しました。;)