Как спроектировать масштабируемый API-интерфейс restful / Non-restful? - PullRequest
Новая
       12

Как спроектировать масштабируемый API-интерфейс restful / Non-restful?

0 голосов
/ 25 июня 2018

У меня есть API 'x', который делает CRUD на 4 параметра сегодня - a, b, c, d. Завтра, если мне придется поддерживать еще несколько параметров в одном и том же API из-за изменения требований, каков наилучший способ справиться с этим?

Стоит ли мне обновлять свою БД новыми введенными параметрами и продолжать делать это каждый раз, когда меняется требование?

Один из моих коллег предложил, чтобы API принимал объект JSON, который может принимать любой набор параметров и любой набор пар ключ-значение. Каждый раз, когда я получаю новый набор пары ключ-значение через этот JSON, я обновляю свою таблицу параметров на это значение, и затем требования могут меняться по мере необходимости.

Я думаю, что это будет очень трудно поддерживать между клиентами, поскольку API будет буквально принимать любую пару ключ-значение, и, следовательно, одна платформа может обсуждать отправку этих пар ключ-значение в одном формате, в то время как другая будет готова отправлять это в другом формате. Кроме того, будет трудно ввести валидации и проверить необязательные и обязательные параметры.

Любые выводы приветствуются

1 Ответ

0 голосов
/ 26 июня 2018

В моем ответе есть немного нюансов, так что будьте осторожны.

Я считаю, что на практике мы не вносим так много изменений в наши API, и когда мы делаем это, мы часто можем сделать это таким образомгде это обратно совместимо.Это означает, что мы добавляем необязательные поля.

Если вы управляете всеми клиентами, это также довольно просто, потому что вы можете просто обновить все из них, чтобы это не было проблемой.

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

Существует более 1 способа решить эту проблему, но я рекомендую использовать следующую модель github.

Для более значительных изменений они меняют заголовок Content-Type.В настоящее время Content-Type для запросов на github: 

Accept: application/vnd.github.v3+json

До того, как они произвели серьезное изменение, оно было: 

Accept: application/vnd.github.v2+json

Для экспериментальных API, которые подвержены изменениям, они используют экспериментальныеContent-Type: 

Accept: application/vnd.github.mister-fantastic-preview+json

Обычно эта идея предпочтительна для спокойного дизайна, но это не единственное решение.

...