В ежедневной разработке всегда открыты различные интерфейсы. Front-end и back-end интерфейсы передачи данных, интерфейсы сторонних бизнес-платформ. Внешние и внутренние интерфейсы передачи данных платформы обычно обмениваются данными в среде интрасети и используют структуру безопасности, поэтому безопасность может быть хорошо защищена. В этой статье основное внимание уделяется тому, как разработать бизнес-интерфейс для сторонней платформы? Какие вопросы мы должны рассмотреть?
В основном из трех вышеперечисленных аспектов для разработки безопасного интерфейса API.
проблема безопасности
Проблема безопасности — это спецификация, которую должен гарантировать интерфейс. Если интерфейс не может гарантировать безопасность, тогда ваш интерфейс эквивалентен прямому доступу к общедоступной сетевой среде и опустошению со стороны других.
1.1 Предпосылки для вызова интерфейса — токен
Получение токена обычно включает несколько параметровappid,appkey,timestamp,nonce,sign. Мы используем вышеуказанные параметры для получения учетных данных вызывающей системы.
appidа такжеappkeyВы можете подать заявку онлайн напрямую через платформу или напрямую оформить в автономном режиме.appidглобально уникален, каждыйappidбудет соответствовать клиенту,appkeyТребуется высокая конфиденциальность.
timestampэто отметка времени, использующая текущую отметку времени unix системы. Цель временных меток — смягчить DOS-атаки. Предотвращает запросы, которые всегда пытаются запросить интерфейс после перехвата. Сторона сервера устанавливает порог отметки времени.Если отметка времени запроса и время сервера превышают порог, ответ не выполняется.
nonceявляется случайным значением. Случайное значение в основном для увеличенияsignИзменчивость интерфейса может также защитить идемпотентность интерфейса, два соседних запросаnonceДубликаты не допускаются, если дубликаты считаются дубликатами, ответ не будет получен.
signявляется сигнатурой параметра, которая будетappkey,timestamp,nonceСращивание их вместе для шифрования md5 (конечно, не проблема использовать другие методы для необратимого шифрования).
token, используя параметрappid,timestamp,nonce,signчтобы получить токен в качестве единственного удостоверения для системного вызова.tokenОн может быть установлен как действующий один раз (это более безопасно) или может быть настроен как чувствительный ко времени. Если он действителен один раз, частота запросов этого интерфейса может быть очень высокой.tokenЕго рекомендуется добавлять в заголовок запроса, чтобы его можно было полностью отличить от бизнес-параметров.
1.2 Использование POST в качестве метода запроса интерфейса
Двумя наиболее распространенными способами вызова интерфейса являются GET и POST. Разница между ними также очевидна: запрос GET будет отображать параметры в URL-адресе браузера, а также существует ограничение на длину. Для повышения безопасности все интерфейсы используют POST-запросы.
1.3 Белый список клиентских IP-адресов
Белый список IP-адресов относится к открытию прав доступа интерфейса к некоторым IP-адресам. Таким образом, можно избежать атак доступа с других IP-адресов.Трудный момент при настройке белого списка IP-адресов заключается в том, что при переносе вашего клиента вам необходимо повторно связаться с поставщиком услуг, чтобы добавить новый белый список IP-адресов. Есть много способов установить белый список IP-адресов.В дополнение к традиционному брандмауэру, компонент Sentinel, предоставляемый spring cloud alibaba, также поддерживает настройку белого списка. Чтобы уменьшить сложность API, рекомендуется использовать правила брандмауэра для внесения в белый список.
1.4 Единый интерфейс для ограничения IP-тока
Ограничение тока предназначено для лучшего поддержания стабильности системы. Используйте redis для подсчета количества вызовов интерфейса, ip + адрес интерфейса в качестве ключа, количество посещений в качестве значения, значение + 1 для каждого запроса и установите время истечения, чтобы ограничить частоту вызовов интерфейса.
1.5 Запись журналов запросов интерфейса
Используйте aop для глобальной записи журналов запросов, быстрого определения расположения ненормальных запросов и устранения причины проблемы.
1.6 Десенсибилизация конфиденциальных данных
В процессе вызова интерфейса могут быть задействованы конфиденциальные данные, такие как номер заказа.Такие данные обычно нуждаются в десенсибилизации, и наиболее распространенным методом является шифрование. Шифрование более безопасноRSAАсимметричное шифрование. Алгоритмы асимметричного шифрования имеют два ключа, которые совершенно разные, но точно совпадают. Шифрование и дешифрование открытого текста может быть выполнено только с использованием совпадающей пары открытого и закрытого ключей.
Две идемпотентные задачи
Идемпотентность означает, что результат выполнения любого количества запросов имеет то же влияние, что и результат выполнения одного запроса. Грубо говоря, операция запроса не повлияет на сами данные независимо от того, сколько раз они запрашиваются, поэтому сама операция запроса является идемпотентной. Но новая операция будет меняться каждый раз при выполнении базы данных, поэтому она не является идемпотентной.
Есть много идей решения проблемы идемпотента, вот более строгая. Предоставляет интерфейс для генерации случайных чисел, которые являются глобально уникальными. Привести случайное число при вызове интерфейса. Для первого вызова, после успешной бизнес-обработки, в качестве ключа используется случайное число, результат операции используется в качестве значения, хранящегося в Redis, и одновременно устанавливается время истечения срока действия. Второй вызов, query redis, если ключ существует, подтверждается повторной отправкой, и сразу возвращается ошибка.
Три проблемы стандартизации данных
3.1 Контроль версий
Набор зрелых документов API после публикации не может изменять интерфейс по своему усмотрению. В настоящее время, если вы хотите добавить или изменить интерфейс, вам необходимо добавить контроль версий.Номер версии может быть целым числом или числом с плавающей запятой. Как правило, адрес интерфейса содержит номер версии.http://ip:порт//v1/список.
3.2 Спецификация кода состояния ответа
Мощный API также должен предоставлять простые и четкие значения ответов, и вы можете примерно определить проблему на основе кода состояния. Мы используем код статуса http для инкапсуляции данных, например, 200 означает, что запрос выполнен успешно, 4xx означает ошибку клиента, а 5xx означает внутреннюю ошибку на сервере. Ссылка на дизайн кода состояния выглядит следующим образом:
| Классификация | описывать |
|---|---|
| 1xx | Информация, сервер получил запрос и запрашивающей стороне необходимо продолжить операцию |
| 2xx | успех |
| 3xx | Перенаправление, дальнейшие действия, необходимые для выполнения запроса |
| 4xx | Ошибка клиента, запрос содержит синтаксическую ошибку или запрос не может быть выполнен |
| 5xx | Ошибка сервера |
Класс перечисления кодов состояния:
public enum CodeEnum {
// 根据业务需求进行添加
SUCCESS(200,"处理成功"),
ERROR_PATH(404,"请求地址错误"),
ERROR_SERVER(505,"服务器内部发生错误");
private int code;
private String message;
CodeEnum(int code, String message) {
this.code = code;
this.message = message;
}
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
3.3 Унифицированный формат данных ответа
Чтобы облегчить ответ клиенту, данные ответа будут содержать три атрибута: код состояния (код), описание информации (сообщение) и данные ответа (данные). Клиент может быстро узнать интерфейс по коду состояния и информационному описанию.Если код состояния возвращается успешно, он начнет обрабатывать данные.
Определение результата ответа и общие методы:
public class R implements Serializable {
private static final long serialVersionUID = 793034041048451317L;
private int code;
private String message;
private Object data = null;
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
public Object getData() {
return data;
}
/**
* 放入响应枚举
*/
public R fillCode(CodeEnum codeEnum){
this.setCode(codeEnum.getCode());
this.setMessage(codeEnum.getMessage());
return this;
}
/**
* 放入响应码及信息
*/
public R fillCode(int code, String message){
this.setCode(code);
this.setMessage(message);
return this;
}
/**
* 处理成功，放入自定义业务数据集合
*/
public R fillData(Object data) {
this.setCode(CodeEnum.SUCCESS.getCode());
this.setMessage(CodeEnum.SUCCESS.getMessage());
this.data = data;
return this;
}
}
Суммировать
В этой статье обсуждаются спецификации дизайна API с точки зрения безопасности, идемпотентности, спецификации данных и т. д. Кроме того, хороший API также имеет отличную документацию по интерфейсу. Удобочитаемость документации по интерфейсу очень важна, хотя многие программисты не любят писать документацию и не любят, когда другие не пишут документацию. Чтобы не увеличивать нагрузку на программистов, рекомендуется использовать swagger или другие инструменты управления интерфейсом.Благодаря простой настройке можно протестировать связность интерфейсов во время разработки, а также можно генерировать автономные документы для управления API после выхода в онлайн.
Обратите внимание, не потеряйтесь
Если вы считаете, что статья хорошая, добро пожаловатьСфокусируйся на,подобно,собирать, ваша поддержка является движущей силой моего творчества, всем спасибо.
Если есть проблема со статьей, пожалуйста, не скупитесь, пожалуйста, оставьте сообщение и укажите это, и я проверю и изменю его вовремя.
Если вы хотите узнать обо мне больше, вы можете ввести в поиск "Путешествие на Яву" обратить внимание. Отвечать"1024», чтобы получить обучающие видео и красивые электронные книги. Отправляйте технические статьи вовремя в 7:30 каждый день, чтобы вам не было одиноко по дороге на работу, и ежемесячно проводится мероприятие по доставке книг, которое поможет вам улучшить свою физическую силу!