Предложение по структуре URL-адреса REST API

#.net #spring #spring-boot #rest #.net-core

#.net #весна #весенняя загрузка #отдых #.net-ядро #rest

Вопрос:

В моем SQL есть 2 таблицы, ЭЛЕМЕНТЫ и КНИГИ. Поэтому я хочу позволить участникам ВЫПУСКАТЬ, ОБНОВЛЯТЬ и ВОЗВРАЩАТЬ книги. Итак, все это запрос на ИСПРАВЛЕНИЕ, который обновляет определенную строку в таблице. Но для этого мне нужно будет включить глагол в URL (ВЫДАВАТЬ, ОБНОВЛЯТЬ или ВОЗВРАЩАТЬ). Хорошая ли это структура URL? Если плохо, как мне подойти к этому. схема базы данных

Здесь ограничения: 1 книга имеет только одну копию, а у книги только 1 автор

ОБНОВЛЕНИЕ: теперь я изменил схему своей базы данных и перенес некоторые свойства в другую таблицу с именем Transactions. Теперь я могу использовать POST (выпустить книгу / добавить строку в транзакцию), PATCH (обновить книгу / изменить дату выполнения транзакции) и DELETE (вернуть книгу / удалить строку из транзакции). Базовый URL-адрес остается одинаковым для всех. Меняются только методы.

Базовый URL: /api/members/{id}/books/{id}/

Ответ №1:

вы должны попробовать что-то вроде приведенного ниже, используя PathVariable .

путь:— /v1/members/{id}

RequestBody:—

 {
               member name="XXX", or email
                bookname="XXXX",
                status="issue/return/renew"
                 }

затем вы должны указать действительный идентификатор и имя участника или (идентификатор и адрес электронной почты).

 if(Success)
 read request and perform a/c that 
else
  throw member not found.

1. Я обновил свою схему БД. Является ли логика в обновлении вопроса хорошим дизайном?

2. это хорошо, если вы хотите, но я бы посоветовал вам воспользоваться преимуществами spring-boot, я имею в виду использовать концепцию OneToMany или ManyToMany. это будет легко для вас только в будущем

3. А также примите любой из приведенных выше ответов, если они действительно помогли вам, чтобы другие люди легко поняли идею.

Ответ №2:

Формально говоря, выпуск, возврат и обновление называются «отглагольным существительным», так что все в порядке. В любом случае, эта структура API звучит нормально.

На вашем месте я бы проверил, не является ли POST метод maybe более подходящим для подобных операций.