Чому конвенція говорить, що назви таблиць БД повинні бути поодинокими, але RESTful ресурси множиною?

Це досить усталене умовлення, що назви таблиць бази даних, принаймні, у SQL, повинні бути єдиними. SELECT * FROM user;Дивіться це питання та обговорення .

Також досить усталеною умовою є те, що імена ресурсів RESTful API повинні бути множинними. GET /users/123і POST /usersдивіться цей .

У найпростішому API, що підтримує базу даних, ім'я ресурсу в URL буде таблицею, а елементи даних у URL-адресі та органи запиту / відповіді відображатимуться безпосередньо у стовпці БД. Концептуально я не бачу різниці між оперуванням даними через цей теоретичний API, а не оперуванням ним безпосередньо через SQL. І через це різниця в називанні конвенцій між userі usersне має для мене сенсу.

Як можна виправдати різницю плюралізації, коли, концептуально, API REST та SQL роблять те саме?

Специфікація REST (незалежно від рівня, який ви хочете пройти) не була розроблена як доступ до бази даних. Він намагається навести стандартизацію доступу до API. Згадані конвенції SQL (хочете ви їх використовувати чи ні) не розроблені з урахуванням доступу API. Вони призначені для написання запитів SQL.

Таким чином, проблема розпакувати тут - це концептуальне розуміння того, що API відображається безпосередньо в базі даних. Ми можемо вважати, що це описується як анти-візерунок, принаймні , ще до 2009 року .

Основна причина цього погана? Код, що описує "як ця операція впливає на мої дані?" стає кодом клієнта .

Це має досить жахливий вплив на API. (не вичерпний список)

Це ускладнює інтеграцію з API

Я уявляю кроки зі створення нового користувача, задокументованого як щось подібне:

1. POST /users { .. }
2. POST /usersettings { .. } з деякими значеннями за замовчуванням
3. POST /confirmemails { .. }

Але як ви впораєтеся з невдачею кроку №2? Скільки разів ця ж логіка обробки копіює-pasta'd іншим клієнтам вашого API?

Ці операції з даними часто простіше проводити послідовність на стороні сервера, при цьому ініціюються у клієнта як одна операція. Напр POST /newusersetup. DBA можуть розпізнати це як збережену процедуру, але операція API може мати наслідки, крім самого бази даних.

Забезпечення API стає чорною дірою відчаю

Скажімо, вам потрібно об’єднати два облікові записи користувачів.

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

Як ви встановите дозвіл користувача, щоб дозволити функцію злиття, не дозволяючи видалити користувача? Чи видалення користувача навіть справедливо представлено, DELETE /users/1коли воно /usersettingsтакож існує?

Операції API слід розглядати як операції на рівні вищого рівня (ніж база даних), які можуть спричинити багаторазові зміни в системі.

Технічне обслуговування стає складніше

... тому що ваші клієнти залежать від вашої структури бази даних.

На основі мого досвіду роботи з цим сценарієм:

• Ви не можете перейменовувати або видаляти існуючі таблиці / стовпці. Навіть коли вони неправильно названі для їх функції або більше не використовуються. Клієнти зламаються.
• Нові функції не можуть змінювати існуючі структури даних, тому її дані та функціональні можливості часто штучно відокремлюються, навіть коли цілісно належать до існуючої функції.
• Базу коду поступово стає важче зрозуміти через фрагментацію, заплутаність імен та залишений багаж, який неможливо видалити безпечно.
• Всі, крім банальних змін, стають все більш ризикованими та трудомісткими.
• Система застоюється і врешті-решт замінюється.

Не піддавайте структуру вашої бази даних безпосередньо клієнтам ... особливо клієнтам, над якими ви не контролюєте розвиток. Використовуйте API, щоб звузити клієнта до справедливих операцій.

Отже, якщо ви використовуєте API як просто інтерфейс прямо в базу даних, плюралізація - це найменший стурбованість. Окрім експерименту, що викидається, я б запропонував витратити деякий час на визначення операцій вищого рівня, які повинен представляти API. І якщо ви дивитесь на це таким чином, немає конфлікту між множиними іменами сутності API та сингулярними іменами сутності SQL. Вони там з різних причин.

API REST та SQL НЕ "роблять те саме"

ОП просить:

Як можна виправдати різницю плюралізації, коли, концептуально, API REST та SQL роблять те саме?

Так, але коник може здатися, що інтерфейс RESTful та таблиці SQL "роблять те саме", але хороша гігієна програмування говорить нам про те, що між API REST та базою даних завжди є проміжний шар. Ігнорувати цей момент - це відхилитися від шляху до просвітлення програмного забезпечення! :)

Тож RESTful API та таблиці SQL можуть із задоволенням слідувати власним ідіоматичним умовам іменування, які добре задокументовані та детально обговорені в інших місцях.