Dlaczego konwencja mówi, że nazwy tabel DB powinny być pojedyncze, a zasoby RESTful w liczbie mnogiej?

Jest to dość ugruntowana konwencja, że ​​nazwy tabel bazy danych, przynajmniej w SQL, powinny być pojedyncze. SELECT * FROM user;Zobacz to pytanie i dyskusję .

Jest to również dość popularna konwencja, że ​​nazwy zasobów interfejsu API RESTful powinny być w liczbie mnogiej. GET /users/123i POST /userszobacz to .

W najprostszym API opartym na bazie danych nazwą zasobu w adresie URL byłaby tabela, a elementy danych w adresie URL i treściach żądania / odpowiedzi byłyby mapowane bezpośrednio na kolumny w DB. Pod względem koncepcyjnym nie widzę różnicy między operowaniem na danych za pośrednictwem tego teoretycznego interfejsu API a operowaniem na nich bezpośrednio za pomocą SQL. Z tego powodu różnica w konwencjach nazewnictwa między useri usersnie ma dla mnie sensu.

Jak można uzasadnić różnicę w liczbie mnogiej, gdy koncepcyjnie interfejs API REST i SQL robią to samo?

Specyfikacja REST (niezależnie od poziomu, z którym chcesz przejść) nie została zaprojektowana jako dostęp do bazy danych. Stara się doprowadzić do standaryzacji dostępu do interfejsu API. Wspomniane konwencje SQL (czy chcesz ich używać, czy nie) nie zostały zaprojektowane z myślą o dostępie do API. Służą do pisania zapytań SQL.

Problemem do rozpakowania jest tutaj koncepcyjne zrozumienie, że interfejs API mapuje bezpośrednio na bazę danych. Możemy to znaleźć jako anty-wzór, przynajmniej od 2009 roku .

Czy główny powód jest zły? Kod opisujący „jak ta operacja wpływa na moje dane?” staje się kodem klienta .

Ma to dość okropny wpływ na API. (nie wyczerpująca lista)

Utrudnia to integrację z API

Wyobrażam sobie kroki, aby utworzyć nowego użytkownika udokumentowanego jako coś takiego:

1. POST /users { .. }
2. POST /usersettings { .. } z pewnymi wartościami domyślnymi
3. POST /confirmemails { .. }

Ale jak sobie poradzić z niepowodzeniem kroku # 2? Ile razy ta sama logika obsługi kopiuje makaron innym klientom interfejsu API?

Te operacje na danych są często łatwiejsze do sekwencjonowania po stronie serwera, a inicjowane są przez klienta jako pojedyncza operacja. Np POST /newusersetup. DBA mogą rozpoznać to jako procedurę przechowywaną, ale działanie interfejsu API może mieć skutki wykraczające poza samą bazę danych.

Zabezpieczenie API staje się czarną dziurą rozpaczy

Powiedzmy, że musisz połączyć dwa konta użytkowników.

1. GET /users/1
2. PUT /users/2 { .. }
3. DELETE /users/1

Jak zamierzasz skonfigurować uprawnienia użytkownika, aby zezwolić na funkcję scalania, a jednocześnie nie zezwala na usunięcie użytkownika? Czy usunięcie użytkownika jest nawet sprawiedliwie reprezentowane przez, DELETE /users/1kiedy /usersettingsrównież istnieje?

Operacje API należy traktować jako operacje na wyższym poziomie (niż baza danych), które mogą powodować wiele zmian w systemie.

Konserwacja staje się trudniejsza

... ponieważ Twoi klienci są zależni od struktury bazy danych.

Na podstawie mojego doświadczenia z tym scenariuszem:

• Nie można zmienić nazwy ani usunąć istniejących tabel / kolumn. Nawet jeśli są niepoprawnie nazwane dla swoich funkcji lub nie są już używane. Klienci się zepsują.
• Nowe funkcje nie mogą zmienić istniejących struktur danych, więc ich dane i funkcje są często sztucznie oddzielone, nawet jeśli całościowo należą do istniejącej funkcji.
• Baza kodu staje się coraz trudniejsza do zrozumienia ze względu na fragmentację, mylące nazwy i resztki bagażu, których nie można bezpiecznie usunąć.
• Wszystkie zmiany oprócz trywialnych stają się coraz bardziej ryzykowne i czasochłonne.
• System zastyga i ostatecznie zostaje wymieniony.

Nie ujawniaj struktury bazy danych bezpośrednio klientom ... zwłaszcza klientom, nad którymi nie masz kontroli rozwojowej. Użyj interfejsu API, aby zawęzić klienta do prawidłowych operacji.

Więc jeśli używasz API jako interfejsu bezpośrednio do bazy danych, pluralizacja jest najmniejszym zmartwieniem. W przypadku eksperymentu innego niż jednorazowe sugeruję poświęcić trochę czasu na określenie operacji wyższego poziomu, które powinien reprezentować interfejs API. A kiedy spojrzysz na to w ten sposób, nie ma konfliktu między pluralizowanymi nazwami encji API a pojedynczymi nazwami encji SQL. Są tam z różnych powodów.

Interfejs API REST i SQL NIE „robią tego samego”

OP pyta:

Jak można uzasadnić różnicę w liczbie mnogiej, gdy koncepcyjnie interfejs API REST i SQL robią to samo?

Ach, ale konik polny, może się wydawać, że interfejs RESTful i tabele SQL „robią to samo”, ale dobra higiena programowania mówi nam, że zawsze istnieje warstwa pośrednia, która pośredniczy między interfejsem API REST a bazą danych. Zignorowanie tego punktu oznacza zejście ze ścieżki do oświecenia programowego! :)

Dzięki temu interfejsy API RESTful i tabele SQL mogą z radością przestrzegać własnych idiomatycznych konwencji nazewnictwa, które są dobrze udokumentowane i szczegółowo omówione w innym miejscu.