Сегодня, когда преобладают распределенные и микросервисы, в большинстве проектов используется среда микросервисов, которая разделяет интерфейс и серверную часть. Отступление: Обязанности фронтенда и бэкэнда становятся все более и более ясными.Сейчас фронтенд называется большим фронтендом, а стек технологий и экосистема очень зрелы.В прошлом бэкэнд Персонал смотрел свысока на фронтенд-персонал, и теперь бэкэнд-персоналу нужно переосмыслить интерфейс, интерфейс уже очень систематичен.
Общая архитектура общей системы выглядит следующим образом:
Следует отметить, что некоторые мелкие партнеры ответят, что эта архитектура слишком проста, слишком низка, никаких шлюзов, кеша, промежуточного программного обеспечения сообщений, ничего из этого. Поскольку Lao Gu в основном представляет интерфейс API, поэтому мы сосредоточимся на сути, а другие партнеры по модулям сами дополнят его.
интерфейс взаимодействия
Фронтенд взаимодействует с бэкендом. Фронтенд запрашивает URL-путь в соответствии с соглашением и передает соответствующие параметры. Бэкенд-сервер получает запрос, выполняет бизнес-обработку и возвращает данные на фронтенд .
Спокойный стиль URL-пути и требования заголовка публичного запроса входящих параметров (таких как: app_version, api_version, device и т. д.) здесь не представлены, и друзья могут понять это сами, и это относительно просто .
Сосредоточиться на том, как внутренний сервер реализует возврат данных во внешний интерфейс?
формат возврата
Когда серверная часть возвращается во внешний интерфейс, мы обычно используем тело JSON, которое определяется следующим образом:
{
#返回状态码
code:integer,
#返回信息描述
message:string,
#返回值
data:object
}
КОД код состояния
code возвращает код состояния.Как правило, друзья добавляют все, что им нужно во время разработки.
Если интерфейс хочет вернуть исключение разрешения пользователя, добавим код состояния 101. В следующий раз, когда мы захотим добавить исключение параметра данных, добавим код состояния 102. Таким образом, хотя бизнес может быть удовлетворен как обычно, код состояния слишком запутан.
Мы должны иметь возможность обращаться к кодам состояния, возвращаемым HTTP-запросами. Ниже приведены распространенные коды состояния HTTP:
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误
Мы можем обратиться к такому дизайну, это преимущество классифицирует тип ошибки в определенный интервал, если интервала недостаточно, его можно оформить в 4 цифры.
#1000～1999 区间表示参数错误
#2000～2999 区间表示用户错误
#3000～3999 区间表示接口异常
Таким образом, после того, как внешние разработчики получат возвращаемое значение, они смогут приблизительно определить ошибку по коду состояния, а затем быстро найти ее по описанию информации, относящейся к сообщению.
Message
Это поле относительно просто для понимания, то есть, как дружелюбно подсказать при возникновении ошибки. Общий дизайн заключается в разработке вместе с кодом состояния кода, например
Затем определите в перечислении код состояния
Код состояния и информация будут соответствовать друг другу, что упрощает обслуживание.
Data
Тело возвращаемых данных, формат JSON, другое тело JSON в зависимости от бизнеса.
Мы должны разработать класс возвращаемого тела Result
Контроллер уровня управления
Мы будем обрабатывать бизнес-запросы на уровне контроллера и возвращать их во внешний интерфейс, взяв заказ в качестве примера.
Мы видим, что после получения объекта заказа мы используем конструктор Result для его обертывания и присвоения, а затем возвращаем. Вы, ребята, узнали, что упаковка метода строительства не очень хлопотна, мы можем ее оптимизировать.
Эстетически оптимизированный
Мы можем добавить статические методы в класс Result и сразу понять
Затем давайте преобразуем контроллер
Код проще и красивее?
элегантная оптимизация
Выше мы видели, что в класс Result добавлен статический метод, который делает код бизнес-обработки лаконичным. Но вы, ребята, нашли несколько проблем с этим:
1. Возврат каждого метода — это инкапсулированный объект Result, который не имеет бизнес-значения.
2. В бизнес-коде мы вызываем Result.success в случае успеха и вызываем Result.failure в случае аномальных ошибок. это слишком
3. Вышеприведенный код оценивает, является ли идентификатор нулевым.На самом деле, мы можем использовать hibernate validate для проверки, и нет необходимости судить в теле метода.
Наш лучший способ вернуть реальный бизнес-объект напрямую, лучше не менять предыдущий бизнес-способ, как показано ниже.
Это то же самое, что и наш обычный код. Он очень интуитивно понятен и напрямую возвращает объект заказа. Разве это не идеально? Каков план реализации?
План реализации
Ребята, у вас есть идеи, как этого добиться? В этом процессе нам нужно сделать несколько вещей.
1. Определите аннотацию @ResponseResult, указывающую, что значение, возвращаемое этим интерфейсом, необходимо завернуть
2. Перехватите запрос, чтобы определить, нужно ли аннотировать запрос с помощью @ResponseResult.
3. Основным шагом является реализация интерфейсов ResponseBodyAdvice и @ControllerAdvice, чтобы определить, нужно ли оборачивать возвращаемое значение, и, если необходимо, переписать возвращаемое значение интерфейса Controller.
Класс аннотаций
Используется для обозначения возвращаемого значения метода, нужно ли его обернуть
перехватчик
Перехватываем запрос, нужно ли заворачивать возвращаемое этим запросом значение, собственно, при запуске парсинг аннотации @ResponseResult
Основная идея этого кода состоит в том, чтобы получить этот запрос, обернуть ли возвращаемое значение и установить тег атрибута.
Переопределить тело возврата
Вышеприведенный код определяет, требуется ли упаковка возвращаемого значения, и, если необходимо, она упаковывается напрямую. Здесь мы имеем дело только с нормальной и успешной упаковкой, а что если метод сообщит об исключении? Обработка исключений также относительно проста, если вы определяете, является ли тело классом исключения.
Как сделать глобальную обработку исключений, причина для пробела, Лао Гу не будет вводить его здесь, пока мышление ясно, его можно изменить самостоятельно.
Переопределить контроллер
Добавьте аннотацию @ResponseResult в класс контроллера или тело метода, так что все в порядке, просто. Идея дизайна, возвращенная здесь, завершена, она проста и элегантна?
Суммировать
Есть ли еще какие-то возможности для оптимизации в этой схеме, конечно, есть. Например, каждый запрос нужно отражать, нужно ли оборачивать способ получения запроса, по сути, это может быть кеш, и его не нужно каждый раз парсить.
Источник | r6d.cn/tEvn