1

私はRESTfulな方法で公開したいいくつかのエンティティを持つサービスを持っています。いくつかの要件のために、私は自分が良いと思う方法を見つけるのに苦労しています。

これらは、私がサポートする予定の「通常の」操作です。

GET /rest/entity[?filter=<query>] # Return (matching) entities. The filter is optional and just a convenience for us CLI curl-users :)

GET /rest/entity/<id> # Return specific entity

POST /rest/entity # Creates one or more new entities

PUT /rest/entity/<id> # Updates specific entity

PUT /rest/entity # Updates many entities (json-dict or multipart. Haven't decided yet)

DELETE /rest/entity/<id> # Deletes specific entity

DELETE /rest/entity # Deletes all entities (dangerous but very useful to us :)

今、追加の要件：

  • エンティティのセット全体を完全に新しいエンティティのセットに置き換えることができる必要があります（マージは最適化として内部で発生する可能性があります）。

    そのために使用POST /rest/entityすることを考えましたが、その機能を移動しない限り、単一のエンティティを作成する機能が削除されます。他の場所で/rest/ entity / new-styleパスを見たことがありますが、IDで衝突が発生する場合と発生しない場合があるため、IDパスセグメントを再利用するのは常に少し奇妙に思えました（私の場合ではありませんが、そのような名前空間を混ぜると、かゆみが生じます:)

    このタイプの操作の一般的な方法はありますか？また、他のエンティティタイプの同様の非RESTful操作の個別のパスと見なし/rest/import/entityましたが、エンティティのホームパスの外に移動するのは好きではありません。

  • 検証のために、ほとんどの操作を「ドライラン」モードで実行できる必要があります。

    クエリ文字列は通常、アナテマと見なされますが、私はすでにフィルター1の罪人です。検証モードの場合、?validateまたは?dryrunフラグを追加しても大丈夫ですか？誰かが似たようなことをしたことがありますか？欠点は何ですか？これは、ユーザー向けのインターフェースが検証を簡単に実装するための支援として意図されています。

これはめったに触れられない小さな構成サービスであるため、キャッシュメカニズムを使用する必要はないと予想されます。したがって、キャッシュの最適化は厳密には必要ありません。

4

1 に答える 1

2

エンティティのセット全体を完全に新しいエンティティのセットに置き換えることができる必要があります完全に新しいエンティティのセット

それがこれがすることですよね？

PUT /rest/entity

PUTには置換セマンティクスがあります。たぶん、PATCH動詞を使用して、部分的な更新の実行をサポートできます。

個人的には、リソース名を「EntityList」または「EntityCollection」に変更しますが、それは私にとってより明確だからです。

于 2010-10-04T13:34:47.143 に答える