0

メイン プロジェクトのパブリック API を再設計する幸運な選択肢があります。安らかな API を作成するという目標として始まったものは、[多くの追加機能が追加された後]、rest/json-rpc の不一致として終わりました。

ですから、再考して再設計する時が来ました。ただし、より複雑な操作を解決する方法についていくつかのアイデアが必要です。

基本的なCURD操作は既に実装されており、正常に動作します。

各リソースは、階層的なスラッグによってアクセスされます。

GET /project/fubar/fishes

ロケールと出力フォーマットも追加されています。

GET /project/fubar/fishes.en-us.json

わかりました、ここでトリッキーな部分に進みます:

プロジェクトの基本的なリソースは、タイトルとサブノードを持つフォルダーに似ています。「フォルダ」には、サブフォルダとアイテムを含めることができます。

新しいフォルダまたはアイテムをフォルダに追加するベスト プラクティスは何ですか?

PUT/PATCH は、リソースをフォルダーにリンクするためではなく、フォルダーに関する情報を更新するために必要ですか? 新しいフォルダを作成するには POST が必要です。

POST /project/fubar/fishes

もう少し追加すると、フォルダーからフォルダーへのリンク操作とアイテムからフォルダーへのリンク操作を区別するためのベスト プラクティスは何でしょうか。リンクには、ターゲットとは別の名前を付けることができることに注意してください。POSIX システムのシンボリック リンクに似ています。

私の考えは（既存のリソースに対して）です：

POST /project/fubar/fishes
{
   link: /project/fubar/dogs
   title: DOGS!
   type: folder
}

逆はどうでしょうか。リンクを解除しますか？

DELETE /project/fubar/fishes/dogs

しかし、これは良いデザインですか、それとも後で戻ってきますか?

4

1 に答える 1

2

コンテンツ ネゴシエーションを使用する

これを使用することはお勧めしません:

GET /project/fubar/fishes.en-us.json

REST 用語では、これは別のリソースです。

GET /project/fubar/fishes

しかし、私があなたの質問を理解している限り、どちらも同じリソースであり、表現が異なるだけです。

特定の表現でリソースを取得するには、コンテンツ ネゴシエーションを使用します。

GET /project/fubar/fishers
Accept: application/json
Accept-Language: en-us

アイテムはどこにありますか?

あなたの URL にはアイテムが表示されません。あなたが「フォルダ」と呼んでいるものだけです。REST 用語では、これらはコレクション リソースと呼ばれます。コレクション リソースにアイテムを追加するには、それをPOSTing します。アイテムを削除するには、アイテムをDELETEing します。変更された部分をアイテムにPOST追加することで、アイテムの一部を変更します。PUT完全なアイテムをing することで更新します。

システム内のコレクション リソースとアイテムを特定することをお勧めします。

于 2012-11-14T08:08:45.283 に答える