REST API設計でベストなリクエスト

Question

前提

REST API設計についてお聞きしたいです。

sites テーブル

id	name	site_values
xxxxx	google	{"countries": [{"country": "日本": "city": "東京"}, {"country": "アメリカ": "city": "カリフォルニア"}]}

id: varchar
name: varchar
site_values: json

（データは適当です。）

上記のテーブルから特定のcountries（例: index0の日本のデータ）を1件だけ削除したい場合どのようなAPIリクエストを投げるのがベストでしょうか？

考えたリクエストについては以下になります。

DELETE /api/sites/xxxxx/countries

問題点
1件だけ削除するのにcountriesと複数形になってしまうのが少し引っかかっておりどのようなリクエストが良いか迷っています。

テーブル設計が悪いかもしれませんが、この状態だった場合どうするのがベストかを教えていただけますと助かります。

Answer 1

1リソースの削除でも複数形が多いんですかね
「複数のリソースの中の特定idの1個を削除する」と考えれば不自然じゃないのかもしれません

なので階層的にはIDが最後に来る方がふさわしいかも

DELETE /api/sites/countries/xxxxx/

Twitter

DELETE /tweets/:id*

https://developer.twitter.com/en/docs/twitter-api/tweets/manage-tweets/api-reference/delete-tweets-id

Github

/repos/{owner}/{repo}

https://docs.github.com/ja/rest/repos/repos?apiVersion=2022-11-28#delete-a-repository

Answer 2

あなたの考え方次第だと思います。

DB のテーブルのレコードを操作する観点なら部分的な変更 (site_values フィールドの変更) なので HTTP 動詞は PUT、JSON の countries だけに着目してその中の配列の要素を操作するという観点なら DELETE で良いと思います。

Comments

[hello_space]

ご回答いただきありがとうございます🙇‍♂️
Request URLについての質問なのですが、1件だけ削除したいのにcountriesと複数形になっているのはどう思いますでしょうか？
DELETE /api/sites/xxxxx/countries

理想的には
DELETE /api/sites/xxxxx/countries/country_id
のような形だと思いますがcountry_idがない場合はどのようにするのが良さそうでしょうか？
DELETE /api/sites/xxxxx/countries だと複数削除するように見えるので
以下のような形でもおかしくはないでしょうか？それとも複数形のままの方が良いでしょうか？
DELETE /api/sites/xxxxx/country

[退会済みユーザー]

観点は上の回答に書いたどっちなのですか？

[hello_space]

countriesに着目しているのでDELETEで考えております。
観点によっても変わるのでしょうか？

[退会済みユーザー]

> countriesに着目しているのでDELETEで考えております。

元のデータは MySQL のような DB のテーブルにあるのですよね。

ユーザーから見れば、DB の中の特定の一つのレコードの site_values にある JSON 文字列だけが Web API を通じて見えていて、それが処理対象ということでいいのですか？　すなわち以下のような構造ということでいいのですか？

ユーザー ⇔ Web API (site_values の JSON 文字列を処理) ⇔ DB

であれば、上の「site_values の JSON 文字列を処理」というところは質問者さんが考えて実装するということで、

> 特定のcountries（例: index0の日本のデータ）を1件だけ削除したい場合

は以下のようにするのが良いと思います。

DELETE /api/sites/xxxxx/日本

ただし、"country" に重複するものがあるとすると話は変わってきますが。

[退会済みユーザー]

でも、普通 Web API というとユーザーから見た相手は DB のテーブル全体になると思うのですが？　（上のコメントに書いたようなことは少なくとも自分的にはあり得ません）

その場合はレコードの UPDATE を行うことになるはずで、PUT /api/sites/xxxxx/5 (5 はテーブルの主キー）として更新用のデータはフォームに含めて送信するのが普通です。

[hello_space]

> 元のデータは MySQL のような DB のテーブルにあるのですよね。
はい、MySQLを使用しております。

ご理解の通りで合っております。ユーザーにはsite_valuesの作成ボタンと削除ボタンが見えており国の情報をフォームに入れて作成を押すと国の所在地データが作られ、削除を押すと特定のcountriesのデータが消える形です。
なのでDELETEではなくPUTまたはPATCHの方が良いのかもしれません。

[退会済みユーザー]

> ユーザーにはsite_valuesの作成ボタンと削除ボタンが見えており国の情報をフォームに入れて作成を押すと国の所在地データが作られ、削除を押すと特定のcountriesのデータが消える形です。

それは Web API を利用したアプリのように思えるのですが？　

ユーザー ⇔ アプリ ⇔ Web API (site_values の JSON 文字列を処理) ⇔ DB

であれば、話は全く違ってくるのですが・・・

[hello_space]

説明が足りずすみません。
ユーザー ⇔ フロントエンド ⇔ バックエンド API (site_values の JSON 文字列を処理) ⇔ DB
と言った形になります。フロントエンドもバックエンドもDBも全て触ることができます。

[退会済みユーザー]

フロントエンド ⇔ バックエンドの話、即ちユーザーに公開する API の話ではないということですよね。それなら自分のやりたいように、都合がいいようにやればいいのではないですか？　ここで聞く話ではないと思います。