Данная ошибка является ошибкой обработки запроса upload - Решение и исправление самых разных ошибок на TopOshibok.ru

Ошибка обработки запроса upload. Данная ошибка является ошибкой обработки запроса upload и не является ошибкой обработки бизнес-пакета, пожалуйста повторите запрос upload или обратитесь в службу сопровождения. Текст ошибки: Password check for user with login [b1ae5124-1e2c-49e8-af28-4ecedb2cee17 ] has failed.

Данный контроль срабатывает, если неправильно указана комбинация логина и пароля от ЕИС в Системе. Для успешной отправки плана-графика следует:

Необходимо в ЛК заказчика в ЕИС изменить пароль для учетной записи согласно инструкции. Измененный пароль необходимо прописать в Системе. После этого необходимо повторить отправку документа в ЕИС. Ссылка на инструкцию: Изменение пароля учетной записи в ЕИС.

Источник

Вопрос: При отправке информации в ЕИС в Журнале отправки документа в ЕИС содержится информация об ошибке «Ошибка (обязательно устранение): Некорректные данные пользователя. Password check for user with login [здесь логин] has failed. Ошибка обработки запроса upload. Данная ошибка является ошибкой обработки запроса upload и не является ошибкой обработки бизнеспакета, пожалуйста повторите запрос upload или обратитесь в службу сопровождения. Текст ошибки: Password check for user with login [здесь логин] has failed.» (ответ внутри)

03 декабря 2020

Ошибка связана с нарушением интеграции с ЕИС. Необходимо настроить интеграцию РИС с ЕИС. Для этого необходимо в РИС выбрать меню «Настройки» –« Регистрационные данные ЕИС». Во вкладке «ЕИС» поставить галочку «сменить пароль». Появится кнопка «Где взять логин и пароль?». При нажатии на неё будет выведена инструкция, которой необходимо следовать.

Источник

Google Chrome.

Для того, что бы очистить, есть 2 способа:

1) Необходимо нажать сочетание клавиш Ctrl+Shift+Delete(Del)

2) Зайти в меню Google Chrome и нажать на пункт “История”, далее выбрать из списка пункт «История» в появившемся окне нажимаем на кнопку “Очистить историю”. Очистить историю Google Chrome.

Любой из способов Вас переведет на страницу, где будет всплывающее окно, в котором Вы можете выбрать, что необходимо удалить и за какой период. После того как выбрали, нажимайте на кнопку “Очистить историю”.

Yandex browser.

Шаги похожи на те, что описывались выше, так же есть 2 способа: Необходимо нажать сочетание клавиш Ctrl+Shift+Delete(Del) или заходим в меню, что находится справа, там ищем пункт “История” и нажимаем на него. На странице в левой части находим пункт “Очистить историю”, нажимаем на него и Вас перебросит на страницу очистки истории. Удаляем историю Яндекс браузер. Здесь все шаги делаются аналогично, как и для Google Chrome. Выбираем период за который необходимо очистить и все элементы, которые надо очистить. В конце не забиваем нажимать “Очистить историю”.

Opera.

Способы для очистки кэша: Необходимо нажать сочетание клавиш Ctrl+Shift+Delete(Del) или в левом верхнем углу браузера находим значок Оперы и нажимаем на него либо в выпадающем списке ищем пункт “История” и переходим по нему, пункт меню «История». На появившейся странице в левом углу находим кнопку “Очистить историю посещений” и нажимаем на нее. Очистить историю посещений Опера. Удаляем кэш браузера Opera, где выбираем период в списке и ставим галочку на пунктах, которые будем очищать.

Mozilla Firefox.

Как и в предыдущих случаях, первый способ это сочетание клавиш Ctrl+Shift+Delete(Del) или выбрать пункт “Журнал” и в появившемся окне нажать на пункт “Удалить недавнюю историю”. Удалить недавнюю историю Firefox. На экране появится окошко, где в всплывающем окне можно выбрать за какое время и поставить галочку, что необходимо почистить. В конце нажимаем “Сохранить”. Процедура может занять несколько секунд.

Safari .

Что бы очистить кэш, заходим в Сафари и в меню, которое расположено справа, выбираем пункт “Сбросить Safari”. После должно появиться окошко, в котором выбираем необходимые настройки, которые нужно сбросить.

Internet Exploer.

Для очистки кэша можно воспользоваться горячими клавишами Ctrl+Shift+Delete(Del). В появившемся окне выбрать все необходимые элементы, которые нужно удалить. Для второго варианта удаления, переходим в меню и выбираем пункт “Безопасность” далее “Удалить журнал браузера.”. В любом из вариантов, в конечном случае будет выведено всплывающее окно, в котором выбираем необходимые настройки, ставим галочки в необходимых пунктах и в конце нажимаем кнопку “Удалить”.

Источник

Исправлена ошибка, в результате которой при формировании сведений о денежном обязательстве на вкладке «Шаг 4. Проверка и отправка» после нажатия на кнопку «Подписать и направить для постановки на учет» мог некорректно срабатывать автоматический контроль: «Указанные реквизиты в бюджетном обязательстве по контракту не соответствуют реквизитному составу в документе о приемке по связанному контракту.».

Исправлена ошибка, в результате которой при попытке размещения извещения о закупках, загруженного по альтернативной интеграции, мог некорректно срабатывать автоматический контроль: «Размещение документа «» по результатам общественных обсуждений правомочно только на этапе «Подача заявок» в соответствии с приказом Минэкономразвития России от 30.10.2015 № 795 «Об утверждении Порядка обязательного общественного обсуждения закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд в случае, если начальная (максимальная) цена контракта либо цена контракта, заключаемого с единственным поставщиком (подрядчиком, исполнителем), превышает один миллиард рублей»».

Исправлена ошибка, в результате которой при формировании сведений о контракте в реестре контрактов на вкладке «Объект закупки» после изменения значения реквизита «Объект закупки заменен на товар, работу, услугу, качество, технические и функциональные характеристики (потребительские свойства), которых улучшены по сравнению с указанными в контракте» могла происходить длительная загрузка страницы.

Исправлена ошибка, в результате которой при переходе в реестр документов об исполнении контрактов могло возникать сообщение: «Страница временно недоступна. Попробуйте перезагрузить страницу»

Исправлена ошибка, в результате которой при просмотре результатов поиска на списковой форме в реестре документов об исполнении контрактов могло отображаться некорректное значение реквизита «Поставщик».

Исправлена ошибка, в результате которой при подписании документа о приемке в реестре документов об исполнении контрактов после нажатия на кнопку «Подписать» сведения могли некорректно оставаться в статусе «На подписании»

Исправлена ошибка, в результате которой при формировании сведений о денежном обязательстве на вкладке «Шаг 3. Формирование сведений для бухгалтерии» после нажатия на кнопку «Продолжить» мог некорректно срабатывать автоматический контроль: «Внимание! Для сохранения объекта закупки в блоке «Сведения о товаре, работе, услуге» необходимо заполнить поле «Сумма»».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 2. Расшифровка ЗКР, дополнительные сведения» после нажатия на кнопку «Сохранить и проверить на нарушения» могли очищаться значения реквизитов «Банковский счет», «БИК банка, ТОФК», «Наименование банка, ТОФК».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 2. Расшифровка ЗКР, дополнительные сведения» после нажатия на кнопку «Сохранить и проверить на нарушения» могло очищаться значение реквизита «КБК плательщика».

Исправлена ошибка, в результате которой при отправке по интеграции протокола подведения итогов по извещению о закупках в переданных сведениях мог отсутствовать реквизит «rightConcludeContractPrice».

Исправлена ошибка, в результате которой при отправке по интеграции сведений о контракте мог некорректно срабатывать автоматический контроль: «Для объекта закупки должны быть заполнены код и наименование позиции Общероссийского классификатора продукции по видам экономической деятельности (ОКПД2)».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 2. Расшифровка ЗКР, дополнительные сведения» после нажатия на кнопку «Сохранить и проверить на нарушения» мог некорректно срабатывать автоматический контроль: «Итоговая сумма всех распоряжений по этапу с признаком авансового платежа превышает общую сумму аванса по этапу на руб.».

Исправлена ошибка, в результате которой при формировании сведений о контракте в реестре контрактов на вкладке «Информация о поставщике» после добавления поставщика и нажатия на кнопку «Сохранить и проверить на нарушения» мог некорректно срабатывать автоматический контроль: «Сведения об организации (ОГРН: ) не найдены в ЕГРЮЛ».

Исправлена ошибка, в результате которой во время формирования сведений об изменении контракта в реестре контрактов на вкладке «Платежные реквизиты» при добавлении счета могла отсутствовать возможность выбора значения в реквизите «Номер лицевого счета».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 1. Сведения о РСКП, документеосновании» в блоке «Раздел 1. Реквизиты документа» могло некорректно заполняться значение номера контракта в реквизите «Назначение платежа».

Исправлена ошибка, в результате которой при отправке по интеграции извещения о закупках могло возникать сообщение: «Непредвиденная ошибка в интеграционном адаптере ПРИЗ».

Исправлена ошибка, в результате которой при отправке по интеграции извещения о закупках мог некорректно срабатывать автоматический контроль: «В соответствии с п.6. ч.1 ст.33 Закона № 44-ФЗ в случае, если объектом закупки являются лекарственные препараты, предметом закупки не могут быть лекарственные препараты с различными международными непатентованными (химическими, группировочными) наименованиями при условии, что начальная (максимальная) цена контракта (цена лота) превышает предельное значение, установленное Правительством Российской Федерации: 1 млн рублей – для заказчиков, у которых объем денежных средств, направленных на закупку лекарственных средств в предшествующем году, составил менее 500 млн рублей; 2,5 млн рублей – для заказчиков, у которых объем денежных средств, направленных на закупку лекарственных средств в предшествующем году, составил от 500 млн рублей до 5 млрд рублей; 5 млн рублей – для заказчиков, у которых объем денежных средств, направленных на закупку лекарственных средств в предшествующем году, составил более 5 млрд. рублей.».

Исправлена ошибка, в результате которой при отправке по интеграции сведений об исполнении (расторжении) контракта могло возникать сообщение: «Непредвиденная ошибка в интеграционном адаптере РГК».

Реализована доработка, в рамках которой в реестре контрактов изменен алгоритм срабатывания автоматического контроля, проверяющего корректность указания значение номера лицевого счета заказчика в блоке «Реквизиты счета заказчика».

Исправлена ошибка, в результате которой во время формирования сведений об изменении контракта в реестре контрактов на вкладке «Платежные реквизиты» после нажатия на кнопку «Сохранить и проверить на нарушения» мог некорректно срабатывать автоматический контроль: «Должна быть заполнена хотя бы одна строка в блоке «Реквизиты счета поставщика»».

Исправлена ошибка, в результате которой при формировании сведений об исполнении контракта в реестре контрактов могли не прикрепляться документы из соответствующего документа о приемке.

Исправлена ошибка, в результате которой при просмотре печатной формы документа о приемке в реестре документов об исполнении контрактов могло отображаться некорректное значение реквизита «Наименование товара (описание выполненных работ, оказанных услуг), имущественного права».

Исправлена ошибка, в результате которой при поиске объектов контроля, используя параметр поиска «Ответственный сотрудник», в результатах поиска могли отсутствовать соответствующие записи.

Исправлена ошибка, в результате которой при отправке по интеграции протокола извещения о закупках мог некорректно срабатывать автоматический контроль: « Блок «Квалификация участников закупки»

(protocolInfo/applicationsInfo/applicationInfo/admittedInfo/appAdmittedInfo/qualitativeCrit erionInfo/indicatorsInfo/indicatorInfo/qualPurсhaseParticipantsInfo) обязателен для заполнения если в поле «Код критерия»

(protocolInfo/applicationsInfo/applicationInfo/admittedInfo/appAdmittedInfo/criterionInfo/q ualitativeCriterionInfo/code) указано значение «QO» — «Квалификация участников закупки, в том числе наличие у них финансовых ресурсов, на праве собственности или ином законном основании оборудования и других материальных ресурсов, опыта работы, связанного с предметом контракта, и деловой репутации, специалистов и иных работников определенного уровня квалификации» и заполнен блок «Критерий оценки с показателями» (qualitativeCriterionInfo/indicatorsInfo).».

Исправлена ошибка, в результате которой при формировании извещения о закупках на вкладке «Требования к участникам» после нажатия на кнопку «Сохранить и проверить на нарушения» могли некорректно срабатывать автоматические контроли: — «Не заполнено следующее обязательное поле: »; — «При формировании сведений о критериях был установлен критерий «» и к нему добавлен показатель «». Необходимо установить «»»

Исправлена ошибка, в результате которой при формировании сведений об изменении контракта в реестре контрактов после нажатия на кнопку «Направить на контроль и разместить» мог некорректно срабатывать автоматический контроль: «Изменение значения в поле «Основание заключения контракта с единственным поставщиком» или «Способ определения поставщика (подрядчика, исполнителя)» приведет к тому, что информация и документы контракта, которые ранее размещались на официальном сайте ЕИС, не будут размещены на официальном сайте ЕИС согласно ч. 5 ст. 103 Закона № 44-ФЗ. Для осуществления такого изменения обратитесь в службу технической поддержки ЕИС.».

Исправлена ошибка, в результате которой при просмотре печатной формы сведений о бюджетном обязательстве в реестре контрактов могло отображаться некорректное значение реквизита «Наименование юридического лица/ФИО физического лица».

Исправлена ошибка, в результате которой при формировании сведений о бюджетном обязательстве в реестре контрактов в блоке «Контрагенты» могло отсутствовать значение реквизита «КПП крупнейшего налогоплательщика».

Исправлена ошибка, в результате которой при размещении сведений об изменении плана проверок мог некорректно срабатывать автоматический контроль: «Невозможна отмена плановой проверки № , т.к. результаты контроля № по указанной плановой проверке были размещены ранее.».

Исправлена ошибка, в результате которой при отправке по интеграции выписки ЕГРЮЛЕГРИП в переданных сведениях мог отсутствовать блок «AttachmentContentList».

Исправлена ошибка, в результате которой при отправке по интеграции извещения о закупках могло возникать сообщение: «ORA-12899: value too large for column «NOTIF_Z».»DETAILED_INDICATORS».»NAME» (actual: 285, maximum: 200) …».

Исправлена ошибка, в результате которой при отправке по интеграции протокола для извещения о закупках могло возникать сообщение: «Непредвиденная ошибка в интеграционном адаптере ПРИЗ».

Исправлена ошибка, в результате которой при отправке по интеграции сведений об исполнении контракта могли некорректно срабатывать автоматические контроли:
— «Необходимо заполнить сведения об объеме поставленных товаров, выполненных работ, оказанных услуг»;
— «Для объекта закупки значение в поле «Количество поставленных товаров, объем выполненных работ, оказанных услуг» должно быть указано в количественном виде (число), как и в действующей размещенной информации о контракте.».

Исправлена ошибка, в результате которой при формировании сведений о контракте в реестре контрактов на вкладке «Общая информация» после нажатия на кнопку «Сохранить и проверить на нарушения» мог некорректно срабатывать автоматический контроль: «Если установлен признак «Требуется казначейское сопровождение контракта», то должно быть заполнено поле «В том числе сумма казначейского обеспечения обязательств», значение которого не может превышать цену контракта.».

Исправлена ошибка, в результате которой при формировании сведений о контракте в реестре контрактов на вкладке «Платёжные реквизиты» после нажатия на кнопку «Сохранить и проверить на нарушения» мог некорректно срабатывать автоматический контроль: «На вкладке «Платежные реквизиты» в блоке «Реквизиты счета заказчика» должны быть указаны реквизиты открытого в установленном порядке в Федеральном казначействе лицевого счета получателя бюджетных средств.».

Исправлена ошибка, в результате которой при формировании сведений о бюджетном обязательстве в реестре контрактов после нажатия на кнопку «Далее» могло возникать сообщение: «Страница временно не доступна. Попробуйте перезагрузить страницу».

Исправлена ошибка, в результате которой при размещении распоряжения о совершении казначейских платежей после нажатия на кнопку «Подписать» мог некорректно срабатывать автоматический контроль: «Для подписания распоряжения о совершении казначейских платежей главному бухгалтеру организации должно быть в обязательном порядке установлено право доступа «Лицо, уполномоченное на ведение бухгалтерского учета (Главный бухгалтер)», а иным лицам, уполномоченным на подписание вместо главного бухгалтера, должно быть в обязательном порядке установлено право доступа «Лицо, уполномоченное на подписание вместо главного бухгалтера». Указанные права доступа устанавливаются в Личном кабинете организации.»

Исправлена ошибка, в результате которой при аннулировании бюджетного обязательства после нажатия на кнопку «Аннулировать БО» мог некорректно срабатывать автоматический контроль: «Аннулирование БО может осуществляться только в случае, если связанное извещение находится в состоянии «Проект», отменено или признано несостоявшимся.».

Исправлена ошибка, в результате которой при формировании информации о прекращении обязательств поставщика, обеспеченных независимой гарантией в блоке «Информация о независимой гарантии, выданной в качестве обеспечения контракта» могла отсутствовать возможность выбора корректного значения поля «Реестровый номер контракта».

Исправлена ошибка, в результате которой при отправке по интеграции сведений о контракте мог некорректно срабатывать автоматический контроль: «Должен быть указан адрес места нахождения».

Исправлена ошибка, в результате которой при отправке по интеграции уведомления о соответствии контролируемой информации могло возникать сообщение: «Непредвиденная ошибка в интеграционном адаптере Бюджетного контроля».

Исправлена ошибка, в результате которой при поиске отчетов заказчиков в реестре отчетов заказчиков на официальном сайте ЕИС в результатах поиска могли отсутствовать соответствующие записи.

Исправлена ошибка, в результате которой во время формирования сведений о контракте в реестре контрактов на вкладке «Платежные реквизиты» в блоке «Реквизиты счета заказчика» при заполнении реквизита «Номер лицевого счета» могли отображаться не все соответствующие значения.

Исправлена ошибка, в результате которой во время формирования сведений о контракте в реестре контрактов на вкладке «Платежные реквизиты» в блоке «Реквизиты счета заказчика» при заполнении реквизита «Номер лицевого счета» могла отсутствовать возможность выбора лицевого счета, начинающегося на «71».

Исправлена ошибка, в результате которой при попытке сформировать сведения о бюджетном обязательстве в реестре контрактов на вкладке «Документы» в блоке «Сведения о бюджетном обязательстве» после нажатия на кнопку «Сформировать сведения о БО» могло возникать сообщение: «Страница временно недоступна. Попробуйте перезагрузить страницу».

Исправлена ошибка, в результате которой при рассмотрении документа о приёмке в реестр документов об исполнении контрактов на вкладке «Дополнительные документы заказчика» после нажатия на кнопку «Далее» мог некорректно срабатывать автоматический контроль: «Следующие реквизиты, указанные в документе о приемке, не соответствуют связанному бюджетному обязательству (). Необходимо привести в соответствие со связанным бюджетным обязательством. В противном случае денежное обязательство по такому документу не будет поставлено на учет.».

Исправлена ошибка, в результате которой при отправке по интеграции извещения о закупках мог некорректно срабатывать автоматический контроль: «Наименование детализирующего показателя может использоваться только один раз.».

Исправлена ошибка, в результате которой при формировании извещения о закупках на вкладке «Требования к участникам» могла отсутствовать возможность заполнения корректным значением реквизита «Предельное максимальное значение показателя характеристики».

Исправлена ошибка, в результате которой во время формирования сведений о контракте в реестре контрактов на вкладке «Платежные реквизиты» в блоке «Контрагенты и реквизиты счета для уплаты неустоек (штрафов, пеней)» при поиске контрагента в окне «Выбор контрагента, отсутствующего в контракте» по значению реквизита «ИНН» после нажатия на кнопку «Найти» могло возникать сообщение: «Страница временно недоступна. Попробуйте перезагрузить страницу».

Исправлена ошибка, в результате которой при формировании сведений о бюджетном обязательстве в реестре контрактов на вкладке «Общая информация» в блоке «Контрагенты» могла отсутствовать кнопка «Добавить».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 1. Сведения о РСКП, документеосновании» в блоке «Раздел 2. Реквизиты документа-основания» мог отсутствовать реквизит «Счет».

Исправлена ошибка, в результате которой при отправке по интеграции сведений о контракте могло возникать сообщение: «Непредвиденная ошибка в интеграционном адаптере РГК.».

Исправлена ошибка, в результате которой при отправке по интеграции сведений о контракте мог некорректно срабатывать автоматический контроль: «Для объектов закупки : »> объем выполненной работы и/или оказанной услуги превышает объем, указанный в текущей информации об изменении контракта. По каждому объекту закупки скорректируйте значение в поле «Количество» таким образом, чтобы объем выполненных работ и/или оказанных услуг не превышал указанное значение.».

Исправлена ошибка, в результате которой при направлении запроса «getObjectRequest» к сервису отдачи для транспортных пакетов с титулами поставщиков в ответе могло сообщаться об отсутствии записей в очереди отдачи «noRecords = true»

Реализована доработка, в рамках которой при формировании сведений о бюджетном обязательстве:
— на вкладке «Общая информация» в блоке «Контрагенты» изменено правило заполнения значения реквизита «Наименование/ФИО» таким образом, что для поставщика с видом «Физическое лицо РФ» с установленным признаком «Индивидуальный предприниматель» должен дополнительно отображаться текст «Индивидуальный предприниматель» в формате: «, »;
— в окне выбора сведений о контрагенте изменено правило заполнения реквизита «Наименование банка (иной организации), в котором (-ой) открыт счет контрагенту» в соответствии со значением реквизита «Наименование банка, ТОФК» или «Наименование банка, обслуживающего ТОФК получателя» (при наличии).

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 2. Расшифровка РСКП, дополнительные сведения» в блоке «Раздел 4. Реквизиты налоговых платежей» могло отсутствовать значение реквизита «Код по ОКТМО».

Исправлена ошибка, в результате которой во время осуществления контроля сведений об исполнении контракта при просмотре печатной формы в блоке «Раздел V. Информация о начислении неустоек (штрафов, пеней)» могло отображаться некорректное значение реквизита «Размер начисленной неустойки (штрафа, пени)».

Исправлена ошибка, в результате которой при поиске объекта контроля по значению параметра «Подписал» после нажатия «Применить» в результатах поиска могли отсутствовать соответствующие записи.

Исправлена ошибка, в результате которой при переходе в карточку извещения о закупках (223-ФЗ) на официальном сайте ЕИС могло возникать сообщение: «Запрашиваемая страница временно недоступна. Попробуйте повторить попытку позже.».,

Исправлена ошибка, в результате которой при формировании сведений о контракте в реестре контрактов на вкладке «Общая информация» после нажатия на кнопку «Далее» могло возникать сообщение: «Страница временно недоступна. Попробуйте перезагрузить страницу.».

Исправлена ошибка, в результате которой при формировании сведений о бюджетном обязательстве в реестре контрактов после нажатия на кнопку «Отправить в ФК» мог некорректно срабатывать автоматический контроль: «Сумма платежей в расшифровке бюджетного обязательства не может быть больше цены контракта и меньше цены контракта с учетом этапа, исполненного не на всю сумму фактически проведенной оплаты по контракту . Скорректируйте сумму платежей в расшифровке бюджетного обязательства.».

Исправлена ошибка, в результате которой при переходе в реестр документов об исполнении контрактов могла происходить долгая загрузка страницы

Исправлена ошибка, в результате которой при отправке документа о приёмке в личный кабинет участника закупок сведения могли зависать в статусе «Ошибка доставки».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 1. Сведения о РСКП, документеосновании» в блоке «Раздел 1. Реквизиты документа» могло отображаться некорректное значение реквизита «Назначение платежа».

Исправлена ошибка, в результате которой при отправке по интеграции извещения о закупках могло возникать сообщение: «Данная ошибка является ошибкой обработки запроса upload и не является ошибкой обработки бизнес-пакета, пожалуйста повторите запрос upload или обратитесь в службу сопровождения. Текст ошибки: Неизвестная ошибка: Read timed out.»

Была реализована доработка, в рамках которой в карточках положений о закупках официального сайта ЕИС на вкладке «Общая информация» в блоке «Срок оплаты поставленного товара, выполненной работы (ее результатов), оказанной услуги» в столбце «Срок оплаты (рабочие дни)» изменён заголовок, формат отображения и правило сортировки записей с учетом рабочих и календарных дней.

Была реализована доработка, в рамках которой в карточках типовых положений о закупках официального сайта ЕИС на вкладке «Общая информация» в блоке «Срок оплаты поставленного товара, выполненной работы (ее результатов), оказанной услуги» в столбце «Срок оплаты (рабочие дни)» изменён заголовок, формат отображения и правило сортировки записей с учетом рабочих и календарных дней.

Исправлена ошибка, в результате которой при просмотре карточки извещения о закупках на официальном сайте ЕИС на вкладке «Результаты определения поставщика» в блоке «Электронные документы об исполнении контракта» после нажатия на «Номер реестровой записи» могло возникать сообщение: «Запрашиваемая страница временно недоступна. Попробуйте повторить попытку позже.».

Исправлена ошибка, в результате которой при просмотре карточки положения о закупках на официальном сайте ЕИС на вкладке «Общая информация» могли отображаться не все записи в блоке «Перечень товаров, работ, услуг со сроком оплаты превышающим срок, указанный в части 5.3 статьи 3 закона № 223-ФЗ»

Исправлена ошибка, в результате которой при формировании сведений о плане – графике закупок после направления сведений на согласование в личный кабинет Уполномоченной организации и блокировки связи с данной организацией план — график мог не возвращаться в статус «На подготовке».

Исправлена ошибка, в результате которой при просмотре печатной формы извещения о закупках в блоке «Финансирование за счет бюджетных средств» могло некорректно отображаться значение реквизита «Итого».

Исправлена ошибка, в результате которой при формировании извещения о закупках на вкладке «Общая информация» после нажатия на кнопку «Обновить сведения, сформированные на основе плана — графика» могли не обновляться значения требования проведения обязательного общественного обсуждения закупок

Исправлена ошибка, в результате которой при формировании извещения о закупках на вкладке «Объект закупки» после добавления товара, работы услуги и нажатия на кнопку «Сохранить и проверить извещение на нарушения» мог некорректно срабатывать автоматический контроль: «Для лота не установлено преимущество «Организациям инвалидов (в соответствии со статьей 29 Федерального закона № 44- ФЗ)» и указаны товары, работы, услуги, при закупке которых предоставляются преимущества организациям инвалидов: .»

Исправлена ошибка, в результате которой при формировании извещения о закупках после нажатия на кнопку «Разместить» мог некорректно срабатывать автоматический контроль: «Осуществление закупки не может быть выполнено для организации «» в связи с тем, что она отсутствует в справочнике организаций официального сайта или не имеет полномочия заказчика или для нее нет зарегистрированного права на осуществление закупки.».

Исправлена ошибка, в результате которой при формировании извещения о закупках после нажатия на кнопку «Разместить» мог некорректно срабатывать автоматический контроль: «Для заказчика «» коды бюджетной классификации в требованиях заказчика не соответствуют сведениям принимаемого бюджетного обязательства № .».

Исправлена ошибка, в результате которой при размещении изменения извещения о закупках, загруженного по интеграции, могло возникать сообщение: «Внимание! В результате подготовки документа к размещению возникли ошибки. Пожалуйста, повторите операцию по документу или обратитесь в техническую поддержку.».

Исправлена ошибка, в результате которой при просмотре печатной формы сведений о контракте в реестре контрактов в разделе «Раздел VI. Платёжные реквизиты» могли отображаться некорректные сведения о поставщике в реквизите «Наименование организации, ИНН, КПП / ФИО».

Исправлена ошибка, в результате которой при формировании сведений о контракте в реестре контрактов на вкладке «Объект закупки» после нажатия на кнопку «Сохранить и проверить на нарушения» мог некорректно срабатывать автоматический контроль: «В информации об изменении контракта не могут быть удалены объекты закупки, которые присутствуют в размещенной информации о контракте (его изменении) и были включены в извещение об осуществлении закупки (приглашение).».

Исправлена ошибка, в результате которой при размещении сведений об исполнении контракта в реестре контрактов после нажатия на кнопку «Направить на контроль и разместить» мог некорректно срабатывать автоматический контроль: «Невозможно завершить исполнение по контракту/ по последнему этапу контракта, поскольку существует размещенное в ЕИС решение об одностороннем отказе от исполнения контракта.».

Исправлена ошибка, в результате которой при формировании сведений о бюджетном обязательстве в реестре контрактов после нажатия на кнопку «Подписать и направить в ФК» могло возникать сообщение: «javax.ejb.EJBException:java.lang.IllegalStateException: java.lang.NullPointerExceptionatorg.jboss.as.ejb3@22.0.0. Final//org.jboss.as.ejb3.tx. CMTTxInterceptor…».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 1. Сведения о РСКП, документеосновании» в блоке «Раздел 1. Реквизиты документа» могла отсутствовать возможность заполнения корректным значением реквизита «Сумма в валюте выплаты».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 2. Расшифровка РСКП, дополнительные сведения» в блоке «Раздел 3. Реквизиты контрагента» после выбора значения реквизита «БИК банка, ТОФК» мог заполняться некорректным значением реквизит «Наименование банка, ТОФК».

Исправлена ошибка, в результате которой при формировании распоряжения о совершении казначейских платежей на вкладке «Шаг 2. Расшифровка РСКП, дополнительные сведения» в блоке «Раздел 5. Расшифровка заявки на кассовый расход» мог заполняться некорректным значением реквизит «Код цели плательщика (аналитический код)».

Исправлена ошибка, в результате которой при рассмотрении документа о приёмке в реестре документов об исполнении контрактов на вкладке «Конструктивные решения и виды работ (просмотр)» в блоках «Выполнено с начала выполнения работ» и Выполнено за отчетный период» могло отображаться некорректное значение реквизита «Стоимость».

Исправлена ошибка, в результате которой при формировании уведомления претензионной переписки в реестре документов об исполнении контрактов после нажатия на кнопку «Подписать» могло возникать сообщение: «Ошибка при создании документа error».

Исправлена ошибка, в результате которой при формировании сведений о денежном обязательстве на вкладке «Шаг 3. Формирование сведений для бухгалтерии» после нажатия на кнопку «Продолжить» мог некорректно срабатывать автоматический контроль: «Сумма всех действующих Сведений о ДО в статусе «Поставлено на учет» и «Направлено для постановки на учет» превышает на сумму действующих Сведений о БО в статусе «Поставлено на учет».».

Исправлена ошибка, в результате которой при формировании сведений о результатах контроля на вкладке «Сведения результатов контроля» после нажатия на кнопку «Разместить результаты контроля» могло возникать сообщение: «Системная ошибка».

Исправлена ошибка, в результате которой при осуществлении контроля сведений об исполнении контракта в блоке «Общие сведения» могло некорректно формироваться наименование объекта контроля.

Исправлена ошибка, в результате которой при формировании извещения о закупках на вкладке «Прилагаемые документы» после нажатия на кнопку «Подписать и разместить» могло возникать сообщение: «Внимание! В результате подготовки документа к размещению возникли ошибки. Пожалуйста, повторите операцию по документу или обратитесь в техническую поддержку.».

Исправлена ошибка, в результате которой при формировании результата контроля плана-графика закупок организации заказчика, подпадающей под критерии отправки сведений для автоматизированной проверки, сведения могли не направляться в автоматизированную систему Федерального казначейства.

Источник

Уровень сложности
Сложный

Время на прочтение
12 мин

Количество просмотров 4.4K

Это главы 39 и 40 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Глава 39. Работа с ошибками в HTTP API

Рассмотренные в предыдущих главах примеры организации API согласно стандарту HTTP и принципам REST покрывают т.н. «happy path», т.е. стандартный процесс работы с API в отсутствие ошибок. Конечно, нам не менее интересен и обратный кейс — каким образом HTTP API следует работать с ошибками, и чем стандарт и архитектурные принципы могут нам в этом помочь. Пусть какой-то агент в системе (неважно, клиент или гейтвей) пытается создать новый заказ:

POST /v1/orders?user_id=<user_id> HTTP/1.1
Authorization: Bearer <token>
If-Match: <ревизия>

{ /* параметры заказа */ }

Какие потенциальные неприятности могут ожидать нас при выполнении этого запроса? Навскидку, это:

Запрос не может быть прочитан (недопустимые символы, нарушение синтаксиса).
Токен авторизации отсутствует.
Токен авторизации невалиден.
Токен валиден, но пользователь не обладает правами создавать новый заказ.
Пользователь удалён или деактивирован.
Идентификатор пользователя неверен (не существует).
Ревизия не передана.
Ревизия не совпадает с последней актуальной.
В теле запроса отсутствуют обязательные поля.
Какое-то из полей запроса имеет недопустимое значение.
Превышены лимиты на допустимое количество запросов.
Сервер перегружен и не может ответить в настоящий момент.
Неизвестная серверная ошибка (т.е. сервер сломан настолько, что диагностика ошибки невозможна).

Исходя из общих соображений, соблазнительной кажется идея назначить каждой из ошибок свой статус-код. Скажем, для ошибки (4) напрашивается код 403, а для ошибки (11) — 429. Не будем, однако, торопиться, и прежде зададим себе вопрос с какой целью мы хотим назначить тот или иной код ошибки.

В нашей системе в общем случае присутствуют три агента: пользователь приложения, само приложение (клиент) и сервер. Каждому из этих акторов необходимо понимать ответ на три вопроса относительно ошибки (причём для каждого из акторов ответ может быть разным):

Кто допустил ошибку (конечный пользователь, разработчик клиента, разработчик сервера или какой-то промежуточный агент, например, программист сетевого стека).
- Не забудем учесть тот факт, что и конечный пользователь, и разработчик клиента могут допустить ошибку намеренно, например, пытаясь перебором подобрать пароль к чужому аккаунту.
Можно ли исправить ошибку, просто повторив запрос.
- Если да, то через какое время.
Если повтором запроса ошибку исправить нельзя, то можно ли её исправить, переформулировав запрос.
Если ошибку вообще нельзя исправить, то что с этим делать.

На один из этих вопрос в рамках стандарта HTTP ответить достаточно легко: регулировать желаемое время повтора запроса можно через параметры кэширования ответа и заголовок Retry-After. Также HTTP частично помогает с первым вопросом: для определения, на чьей стороне произошла ошибка, используется первая цифра статус-кода (см. ниже).

Со всеми остальными вопросами, увы, ситуация сильно сложнее.

Клиентские ошибки

Статус-коды, начинающиеся с цифры 4, индицируют, что ошибка допущена пользователем или клиентом (или, по крайней мере, сервер так считает). Обычно, полученную 4xx повторять бессмысленно — если не предпринять дополнительных действий по изменению состояния сервиса, этот запрос не будет выполнен успешно никогда. Однако из этого правила есть исключения, самые важные из которых — 429 Too Many Requests и 404 Not Found. Последняя по стандарту имеет смысл «состояния неопределённости»: сервер имеет право использовать её, если не желает раскрывать причины ошибки. После получения ошибки 404, можно сделать повторный запрос, и он вполне может отработать успешно. Для индикации персистентной ошибки «ресурс не найден» используется отдельный статус 410 Gone.

Более интересный вопрос — а что всё-таки клиент может (или должен) сделать, получив такую ошибку. Как мы указывали в главе «Разграничение областей ответственности», если ошибка может быть исправлена программно, необходимо в машиночитаемом виде индицировать это клиенту; если ошибка не может быть исправлена, необходимо включить человекочитаемые сообщения для пользователя (даже просто «попробуйте начать сначала / перезагрузить приложение» лучше с точки зрения UX, чем «неизвестная ошибка») и для разработчика, который будет разбираться с проблемой.

С восстановимыми ошибками в HTTP, к сожалению, ситуация достаточно сложная. С одной стороны, протокол включает в себя множество специальных кодов, которые индицируют проблемы с использованием самого протокола — такие как 405 Method Not Allowed (данный глагол неприменим к указанному ресурсу), 406 Not Acceptable (сервер не может вернуть ответ согласно Accept-заголовкам запроса), 411 Length Required, 414 URI Too Long и так далее. Код клиента может обработать данные ошибки и даже, возможно, предпринять какие-то действия по их устранению (например, добавить заголовок Content-Length в запрос после получения ошибки 411), но все они очень плохо применимы к ошибкам в бизнес-логике. Например, мы можем вернуть 429 Too Many Requests при превышении лимитов запросов, но у нас нет никакого стандартного способа указать, какой именно лимит был превышен.

Частично проблему отсутствия стандартных подходов к возврату ошибок компенсируют использованием различных близких по смыслу статус-кодов для индикации разных состояний (либо и вовсе выбор произвольного кода ошибки и придания ему нового смысла в рамках конкретного API). В частности, сегодня де-факто стандартом является возврат кода 401 Unauthorized при отсутствии заголовков авторизации или невалидном токене (получение этого кода, таким образом, является сигналом для приложения предложить пользователю залогиниться в системе), что противоречит стандарту (который требует при возврате 401 обязательно указать заголовок WWW-Authenticate с описанием способа аутентификации пользователя; нам неизвестны реальные API, которые выполняют это требованием).

Однако таких кодов, которые могут отражать нюансы одной и той же проблемы, в стандарте очень мало. Фактически, мы приходим к тому, что множество различных ошибок в логике приложения приходится возвращать под очень небольшим набором статус-кодов:

400 Bad Request для всех ошибок валидации запроса (некоторые пуристы утверждают, что, вообще говоря, 400 соответствует нарушению формата запроса — невалидному JSON, например — а для логических ошибок следует использовать код 422 Unprocessable Content; в постановке задачи это мало что меняет);
403 Forbidden для любых проблем, связанных с авторизацией действий клиента;
404 Not Found в случае, если какие-то из указанных в запросе сущностей не найдены либо раскрытие причин ошибки нежелательно;
409 Conflict при нарушении целостности данных;
410 Gone если ресурс был удалён;
429 Too Many Requests при превышении лимитов.

Разработчики стандарта HTTP об этой проблеме вполне осведомлены, и отдельно отмечают, что для решения бизнес-сценариев необходимо передавать в метаданных либо теле ответа дополнительные данные для описания возникшей ситуации («the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition»), что (как и введение новых специальных кодов ошибок) противоречит самой идее унифицированного машиночитаемого формата ошибок. (Отметим, что отсутствие стандартов описания ошибок в бизнес-логике — одна из основных причин, по которым мы считаем разработку REST API как его описал Филдинг в манифесте 2008 года невозможной; клиент должен обладать априорным знанием о том, как работать с метаинформацией об ошибке, иначе он сможет восстанавливать своё состояние после ошибки только перезагрузкой.)

Дополнительно, у проблемы есть и третье измерение в виде серверного ПО мониторинга состояния системы, которое часто полагается на статус-коды ответов при построении графиков и уведомлений. Между тем, ошибки, скрывающиеся под одним статус кодом — например ввод неправильного пароля и истёкший срок жизни токена — могут быть очень разными по смыслу; повышенный фон первой ошибки может говорить о потенциальной попытке взлома путём перебора паролей, а второй — о потенциальных ошибках в новой версии приложения, которая может неверно кэшировать токены авторизации.

Всё это естественным образом подводит нас к следующему выводу: если мы хотим использовать ошибки для диагностики и (возможно) восстановления состояния клиента, нам необходимо добавить машиночитаемую метаинформацию о подвиде ошибки и, возможно, тело ошибки с указанием подробной информации о проблемах — например, как мы предлагали в главе «Описание конечных интерфейсов»:

POST /v1/coffee-machines/search HTTP/1.1

{
  "recipes": ["lngo"],
  "position": {
    "latitude": 110,
    "longitude": 55
  }
}
→
HTTP/1.1 400 Bad Request
X-OurCoffeeAPI-Error-Kind:⮠
  wrong_parameter_value

{
  "reason": "wrong_parameter_value",
  "localized_message":
    "Что-то пошло не так.⮠
    Обратитесь к разработчику приложения.",
  "details": {
    "checks_failed": [{
      "field": "recipe",
      "error_type": "wrong_value",
      "message":
        "Value 'lngo' unknown.⮠
        Did you mean 'lungo'?"
    }, {
      "field": "position.latitude",
      "error_type": "constraint_violation",
      "constraints": {
        "min": -90,
        "max": 90
      },
      "message":
        "'position.latitude' value⮠
        must fall within⮠
        the [-90, 90] interval"
    }]
  }
}

Также напомним, что любые неизвестные 4xx-статус-коды клиент должен трактовать как ошибку 400 Bad Request, следовательно, формат (мета)данных ошибки 400 должен быть максимально общим.

Серверные ошибки

Ошибки 5xx индицируют, что клиент, со своей стороны, выполнил запрос правильно, и проблема заключается в сервере. Для клиента, по большому счёту, важно только то, имеет ли смысл повторять запрос и, если да, то через какое время. Если учесть, что в любых публично доступных API причины серверных ошибок, как правило, не раскрывают — в абсолютном большинстве кодов 500 Internal Server Error и 503 Service Unavailable достаточно для индикации серверных ошибок (второй код указывает, что отказ в обслуживании имеет разовый характер и есть смысл автоматически повторить запрос), или можно вовсе ограничиться одним из них с опциональным заголовком Retry-After.

Для внутренних систем, вообще говоря, такое рассуждение неверно. Для построения правильных мониторингов и системы оповещений необходимо, чтобы серверные ошибки, точно так же, как и клиентские, содержали подтип ошибки в машиночитаемом виде. Здесь по-прежнему применимы те же подходы — использование широкой номенклатуры кодов и/или передача типа ошибки заголовком — однако эта информация должна быть вырезана гейтвеем на границе внешней и внутренней систем, и заменена на общую информацию для разработчика и для конечного пользователя системы с описанием действий, которые необходимо выполнить при получении ошибки.

POST /v1/orders/?user_id=<user id> HTTP/1.1
If-Match: <ревизия>

{ parameters }
→
// Ответ, полученный гейтвеем
// от сервиса обработки заказов,
// метаданные которого будут
// использованы для мониторинга
HTTP/1.1 500 Internal Server Error
// Тип ошибки: получен таймаут от БД
X-OurCoffeAPI-Error-Kind: db_timeout
{ /* Дополнительные данные, например,
     какой хост ответил таймаутом */ }

// Ответ, передаваемый клиенту.
// Детали серверной ошибки удалены
// и заменены на инструкцию клиенту.
// Поскольку гейтвей не знает, был
// ли в действительности сделан заказ,
// клиенту рекомендуется попробовать
// повторить запрос и/или попытаться
// получить актуальное состояние
HTTP/1.1 500 Internal Server Error
Retry-After: 5

{ 
  "reason": "internal_server_error",
  "localized_message": "Не удалось⮠
    получить ответ от сервера.⮠
    Попробуйте повторить операцию
    или обновить страницу.",
  "details": {
    "can_be_retried": true,
    "is_operation_failed": "unknown"
  }
}

Вот здесь мы, однако, вступаем на очень скользкую территорию. Современная практика реализации HTTP-клиентов такова, что безусловно повторяются только немодифицирующие (GET, HEAD, OPTIONS) запросы. В случае модифицирующих запросов разработчик должен написать код, который повторит запрос — и для этого разработчику нужно очень внимательно прочитать документацию к API, чтобы убедиться, что это поведение допустимо и не приведёт к побочным эффектам.

Теоретически идемпотентные методы PUT и DELETE можно вызывать повторно. Практически, однако, ввиду того, что многие разработчики упускают требование идемпотентности этих методов, фреймворки работы с HTTP API по умолчанию перезапросов модифицирующих методов, как правило, не делают, но некоторую выгоду из следования стандарту мы всё же можем извлечь — по крайней мере, сама сигнатура индицирует, что запрос можно повторять.

Что касается более сложных ситуаций, когда мы хотим указать разработчику, что он может безопасно повторить потенциально неидемпотентную операцию, то мы могли бы предложить формат описания доступных действий в теле ошибки… но практически никто не ожидает найти такое описание в самой ошибке. Возможно, потому, что с ошибками 5xx, в отличие от 4xx, программисты практически не сталкиваются при написании клиентского кода, и мало какие тестовые среды позволяют такие ошибки эмулировать. Так или иначе, описывать необходимые действия при получении серверной ошибки вам придётся в документации. (Имейте в виду, что эти инструкции с большой долей вероятности будут проигнорированы. Таков путь.)

Организация системы ошибок в HTTP API на практике

Как понятно из вышесказанного, фактически есть три способа работать с ошибками HTTP API:

Расширительно трактовать номенклатуру статус-кодов и использовать новый код каждый раз, когда требуется индицировать новый вид ошибки. (Автор этой книги неоднократно встречал ситуации, когда при разработке API просто выбирался «похоже выглядящий» статус безо всякой оглядки на его описание в стандарте.)
Полностью отказаться от использования статус-кодов и вкладывать описание ошибки в тело и/или метаданные ответа с кодом 200. Этим путём идут почти все RPC-фреймворки.
- 2а. Вариантом этой стратегии можно считать использование всего двух статус-кодов ошибок (400 для любой клиентской ошибки, 500 для любой серверной), опционально трёх (те же плюс 404 для статуса неопределённости).
Применить смешанный подход, то есть использовать статус-код согласно его семантике для индикации рода ошибки и вложенные (мета)данные в специально разработанном формате для детализации (подобно фрагментам кода, предложенным нами в настоящей главе).

Как нетрудно заметить, считать соответствующим стандарту можно только подход (3). Будем честны и скажем, что выгоды следования ему, особенно по сравнению с вариантом (2а), не очень велики и состоят в основном в чуть лучшей читабельности логов и большей прозрачности для промежуточных прокси.

Глава 40. Заключительные положения и общие рекомендации

Подведём итог описанному в предыдущих главах. Чтобы разработать качественный HTTP API, необходимо:

Описать happy path, т.е. составить диаграмму вызовов для стандартного цикла работы клиентского приложения.
Определить каждый вызов как операцию над некоторым ресурсом и, таким образом, составить номенклатуру URL и применимых методов.
Понять, какие ошибки возможны при выполнении операций и каким образом клиент должен восстанавливаться из какого состояния.
Решить, какая функциональность будет передана на уровень протокола HTTP [какие стандартные возможности протокола будут использованы в сопряжении с какими инструментами разработки] и в каком объёме.
Опираясь на решения 1-4, разработать конкретную спецификацию.
Проверить себя: пройти по пунктам 1-3, написать псевдокод бизнес-логики приложения согласно разработанной спецификации, и оценить, насколько удобным, понятным и читабельным оказался результирующий API.

Позволим себе так же дать несколько советов по code style:

Не различайте пути с / на конце и без него и примите какую-то рекомендацию по умолчанию (мы рекомендуем все пути заканчивать на / — по простой причине, это позволяет разумно описать обращение к корню домена как ГЛАГОЛ /). Если вы решили запретить один из вариантов (скажем, пути без слэша в конце), при обращении по второму варианту должен быть или редирект или однозначно читаемая ошибка.
Включайте в ответы стандартные заголовки — Date, Content-Type, Content-Encoding, Content-Length, Cache-Control, Retry-After — и вообще старайтесь не полагаться на то, что клиент правильно догадывается о параметрах протокола по умолчанию.
Поддержите метод OPTIONS и протокол CORS на случай, если ваш API захотят использовать из браузеров.
Определитесь с правилами выбора кейсинга параметров (и преобразований кейсинга при перемещении параметра между различными частями запроса) и придерживайтесь их.
Всегда оставляйте себе возможность обратно-совместимого расширения операции API. В частности, всегда возвращайте корневой JSON-объект в ответах эндпойтов — потому что приписать новые поля к объекту вы можете, а к массивам и примитивам — нет.
- Отметим также, что пустая строка не является валидным JSON, поэтому корректнее возвращать пустой объект {} там, где ответа не подразумевается (или статус 204 No Content с пустым телом, но тогда эндпойнт нельзя будет расширить в будущем).
Для всех GET-запросов указывайте политику кэширования (иначе всегда есть шанс, что клиент или промежуточный агент придумает её за вас).
Не эксплуатируйте известные возможности оперировать запросами в нарушение стандарта и не изобретайте свои решения для «серых зон» протокола. В частности:
- не размещайте модифицирующие операции за методом GET и неидемпотентные операции за PUT / DELETE;
- соблюдайте симметрию GET / PUT / DELETE методов;
- не позволяйте GET / HEAD / DELETE-запросам иметь тело, не возвращайте тело в ответе метода HEAD или совместно со статус-кодом 204 No Content;
- не придумывайте свой стандарт для передачи массивов и вложенных объектов в query — лучше воспользоваться HTTP-глаголом, позволяющим запросу иметь тело, или, в крайнем случае, передать параметры в виде Base64-кодированного JSON-поля;
- не размещайте в пути и домене URL параметры, по формату требующие эскейпинга (т.е. могущие содержать символы, отличные от цифр и букв латинского алфавита); для этой цели лучше воспользоваться query-параметрами или телом запроса.
Ознакомьтесь хотя бы с основными видами уязвимостей в типичных имплементациях HTTP API, которыми могут воспользоваться злоумышленники:
- CSFR
- SSRF
- HTTP Response Splitting
- Unvalidated Redirects and Forwards
и заложите защиту от этих векторов атак на уровне вашего серверного ПО. Организация OWASP предоставляет хороший обзор лучших security-практик для HTTP API.

В заключение хотелось бы сказать следующее: HTTP API — это способ организовать ваше API так, чтобы полагаться на понимание семантики операций как разнообразным программным обеспечением, от клиентских фреймворков до серверных гейтвеев, так и разработчиком, который читает спецификацию. В этом смысле экосистема HTTP предоставляет пожалуй что наиболее широкий (и в плане глубины, и в плане распространённости) по сравнению с другими технологиями словарь для описания самых разнообразных ситуаций, возникающих во время работы клиент-серверных приложений. Разумеется, эта технология не лишена своих недостатков, но для разработчика публичного API она является выбором по умолчанию — на сегодняшний день скорее надо обосновывать отказ от HTTP API чем выбор в его пользу.

Источник