Как отправить delete запрос из браузера
Мечта, ради которой создавалась Сеть – это общее информационное пространство, в котором мы общаемся, делясь информацией. Его универсальность является его неотъемлемой частью: ссылка в гипертексте может вести куда угодно, будь то персональная, локальная или глобальная информация, черновик или выверенный текст.
Тим Бернес-Ли, Всемирная паутина: Очень короткая личная история
Протокол
Сервер отвечает по тому же соединению:
Браузер берёт ту часть, что идёт за ответом после пустой строки и показывает её в виде HTML-документа.
Информация, отправленная клиентом, называется запросом. Он начинается со строки:
Первое слово – метод запроса. GET означает, что нам нужно получить определённый ресурс. Другие распространённые методы – DELETE для удаления, PUT для замещения и POST для отправки информации. Заметьте, что сервер не обязан выполнять каждый полученный запрос. Если вы выберете случайный сайт и скажете ему DELETE главную страницу – он, скорее всего, откажется.
Ответ сервера также начинается с версии протокола, за которой идёт статус ответа – сначала код из трёх цифр, затем строчка.
За первой строкой запроса или ответа может идти любое число строк заголовка. Это строки в виде “имя: значение”, которые обозначают дополнительную информацию о запросе или ответе. Эти заголовки были включены в пример:
Content-Length: 65585
Content-Type: text/html
Last-Modified: Wed, 09 Apr 2014 10:48:09 GMT
Тут определяется размер и тип документа, полученного в ответ. В данном случае это HTML-документ размером 65’585 байт. Также тут указано, когда документ был изменён последний раз.
По большей части клиент или сервер определяют, какие заголовки необходимо включать в запрос или ответ, хотя некоторые заголовки обязательны. К примеру, Host, обозначающий имя хоста, должен быть включён в запрос, потому что один сервер может обслуживать много имён хостов на одном ip-адресе, и без этого заголовка сервер не узнает, с каким хостом клиент пытается общаться.
Как мы видели в примере, браузер отправляет запрос, когда мы вводим URL в адресную строку. Когда в полученном HTML документе содержатся упоминания других файлов, такие, как картинки или файлы JavaScript, они тоже запрашиваются с сервера.
Веб-сайт средней руки легко может содержать от 10 до 200 ресурсов. Чтобы иметь возможность запросить их побыстрее, браузеры делают несколько запросов одновременно, а не ждут окончания запросов одного за другим. Такие документы всегда запрашиваются через запросы GET.
На страницах HTML могут быть формы, которые позволяют пользователям вписывать информацию и отправлять её на сервер. Вот пример формы:
Начало строки запроса обозначено знаком вопроса. После этого идут пары имён и значений, соответствующие атрибуту name полей формы и содержимому этих полей. Амперсанд (&) используется для их разделения.
В следующей главе мы вернёмся к формам и поговорим про то, как мы можем делать их при помощи JavaScript.
И всё же имя не полностью бессмысленное. Интерфейс позволяет разбирать вам ответы, как если бы это были документы XML. Смешивать две разные вещи (запрос и разбор ответа) в одну – это, конечно, отвратительный дизайн, но что поделаешь.
Отправка запроса
Можно получить из объекта response и другую информацию. Код статуса доступен в свойстве status, а текст статуса – в statusText. Заголовки можно прочесть из getResponseHeader.
Названия заголовков не чувствительны к регистру. Они обычно пишутся с заглавной буквы в начале каждого слова, например “Content-Type”, но “content-type” или “cOnTeNt-TyPe” будут описывать один и тот же заголовок.
Браузер сам добавит некоторые заголовки, такие, как “Host” и другие, которые нужны серверу, чтобы вычислить размер тела. Но вы можете добавлять свои собственные заголовки методом setRequestHeader. Это нужно для особых случаев и требует содействия сервера, к которому вы обращаетесь – он волен игнорировать заголовки, которые он не умеет обрабатывать.
Асинхронные запросы
В примере запрос был окончен, когда заканчивается вызов send. Это удобно потому, что свойства вроде responseText становятся доступными сразу. Но это значит, что программа наша будет ожидать, пока браузер и сервер общаются меж собой. При плохой связи, слабом сервере или большом файле это может занять длительное время. Это плохо ещё и потому, что никакие обработчики событий не сработают, пока программа находится в режиме ожидания – документ перестанет реагировать на действия пользователя.
Если третьим аргументом open мы передадим true, запрос будет асинхронным. Это значит, что при вызове send запрос ставится в очередь на отправку. Программа продолжает работать, а браузер позаботиться об отправке и получении данных в фоне.
Но пока запрос обрабатывается, мы не получим ответ. Нам нужен механизм оповещения о том, что данные поступили и готовы. Для этого нам нужно будет слушать событие “load”.
Так же, как вызов requestAnimationFrame в главе 15, этот код вынуждает нас использовать асинхронный стиль программирования, оборачивая в функцию тот код, который должен быть выполнен после запроса, и устраивая вызов этой функции в нужное время. Мы вернёмся к этому позже.
Получение данных XML
Мы можем получить такой файл следующим образом:
Документы XML можно использовать для обмена с сервером структурированной информацией. Их форма – вложенные теги – хорошо подходит для хранения большинства данных, ну или по крайней мере лучше, чем текстовые файлы. Интерфейс DOM неуклюж в плане извлечения информации, и XML документы получаются довольно многословными. Обычно лучше общаться при помощи данных в формате JSON, которые проще читать и писать – как программам, так и людям.
Это может мешать разработке систем, которым надо иметь доступ к разным доменам по уважительной причине. К счастью, сервер может включать в ответ следующий заголовок, поясняя браузерам, что запрос может прийти с других доменов:
Абстрагируем запросы
В главе 10 в нашей реализации модульной системы AMD мы использовали гипотетическую функцию backgroundReadFile. Она принимала имя файла и функцию, и вызывала эту функцию после прочтения содержимого файла. Вот простая реализация этой функции:
Аргумент callback (обратный вызов) – термин, часто использующийся для описания подобных функций. Функция обратного вызова передаётся в другой код, чтобы он мог позвать нас обратно позже.
Основная проблема с приведённой обёрткой – обработка ошибок. Когда запрос возвращает код статуса, обозначающий ошибку (от 400 и выше), он ничего не делает. В некоторых случаях это нормально, но представьте, что мы поставили индикатор загрузки на странице, показывающий, что мы получаем информацию. Если запрос не удался, потому что сервер упал или соединение прервано, страница будет делать вид, что она чем-то занята. Пользователь подождёт немного, потом ему надоест и он решит, что сайт какой-то дурацкий.
Обработка ошибок в асинхронном коде ещё сложнее, чем в синхронном. Поскольку нам часто приходится отделять часть работы и размещать её в функции обратного вызова, область видимости блока try теряет смысл. В следующем коде исключение не будет поймано, потому что вызов backgroundReadFile возвращается сразу же. Затем управление уходит из блока try, и функция из него не будет вызвана.
Чтобы обрабатывать неудачные запросы, придётся передавать дополнительную функцию в нашу обёртку, и вызывать её в случае проблем. Другой вариант – использовать соглашение, что если запрос не удался, то в функцию обратного вызова передаётся дополнительный аргумент с описанием проблемы. Пример:
Мы добавили обработчик события error, который сработает при проблеме с вызовом. Также мы вызываем функцию обратного вызова с аргументом error, когда запрос завершается со статусом, говорящим об ошибке.
Код, использующий getURL, должен проверять не возвращена ли ошибка, и обрабатывать её, если она есть.
С исключениями это не помогает. Когда мы совершаем последовательно несколько асинхронных действий, исключение в любой точке цепочки в любом случае (если только вы не обернули каждый обработчик в свой блок try/catch) вывалится на верхнем уровне и прервёт всю цепочку.
Обещания
Тяжело писать асинхронный код для сложных проектов в виде простых обратных вызовов. Очень легко забыть проверку на ошибку или позволить неожиданному исключению резко прервать программу. Кроме того, организация правильной обработки ошибок и проход ошибки через несколько последовательных обратных вызовов очень утомительна.
Предпринималось множество попыток решить эту проблему дополнительными абстракциями. Одна из наиболее удачных попыток называется обещаниями (promises). Обещания оборачивают асинхронное действие в объект, который может передаваться и которому нужно сделать какие-то вещи, когда действие завершается или не удаётся. Такой интерфейс уже стал частью текущей версии JavaScript, а для старых версий его можно использовать в виде библиотеки.
Для создания объекта promises мы вызываем конструктор Promise, задавая ему функцию инициализации асинхронного действия. Конструктор вызывает эту функцию и передаёт ей два аргумента, которые сами также являются функциями. Первая должна вызываться в удачном случае, другая – в неудачном.
И вот наша обёртка для запросов GET, которая на этот раз возвращает обещание. Теперь мы просто назовём его get.
Заметьте, что интерфейс к самой функции упростился. Мы передаём ей URL, а она возвращает обещание. Оно работает как обработчик для выходных данных запроса. У него есть метод then, который вызывается с двумя функциями: одной для обработки успеха, другой – для неудачи.
Пока это всё ещё один из способов выразить то же, что мы уже сделали. Только когда у вас появляется цепь событий, становится видна заметная разница.
Вызов then производит новое обещание, чей результат (значение, передающееся в обработчики успешных результатов) зависит от значения, возвращаемого первой переданной нами в then функцией. Эта функция может вернуть ещё одно обещание, обозначая что проводится дополнительная асинхронная работа. В этом случае обещание, возвращаемое then само по себе будет ждать обещания, возвращённого функцией-обработчиком, и успех или неудача произойдут с таким же значением. Когда функция-обработчик возвращает значение, не являющееся обещанием, обещание, возвращаемое then, становится успешным, в качестве результата используя это значение.
Значит, вы можете использовать then для изменения результата обещания. К примеру, следующая функция возвращает обещание, чей результат – содержимое с данного URL, разобранное как JSON:
Последний вызов then не обозначил обработчик неудач. Это допустимо. Ошибка будет передана в обещание, возвращаемое через then, а ведь это нам и надо – getJSON не знает, что делать, когда что-то идёт не так, но есть надежда, что вызывающий её код это знает.
В качестве примера, показывающего использование обещаний, мы напишем программу, получающую число JSON-файлов с сервера, и показывающую во время исполнения запроса слово «загрузка». Файлы содержат информацию о людях и ссылки на другие файлы с информацией о других людях в свойствах типа отец, мать, супруг.
Можно представлять себе, что интерфейс обещаний – это отдельный язык для асинхронной обработки исполнения программы. Дополнительные вызовы методов и функций, которые нужны для его работы, придают коду несколько странный вид, но не настолько неудобный, как обработка всех ошибок вручную.
При создании системы, в которой программа на JavaScript в браузере (клиентская) общается с серверной программой, можно использовать несколько вариантов моделирования такого общения.
Общепринятый метод – удалённые вызовы процедур. В этой модели общение идёт по шаблону обычных вызовов функций, только функции эти выполняются на другом компьютере. Вызов заключается в создании запроса на сервер, в который входят имя функции и аргументы. Ответ на запрос включает возвращаемое значение.
Данные путешествуют по интернету по длинному и опасному пути. Чтобы добраться до пункта назначения, им надо попрыгать через всякие места, начиная от Wi-Fi сети кофейни до сетей, контролируемых разными организациями и государствами. В любой точке пути их могут прочитать или даже поменять.
Упражнения
Согласование содержания (content negotiation)
Наконец, попробуйте запросить содержимое типа application/rainbows+unicorns и посмотрите, что произойдёт.
Ожидание нескольких обещаний
У конструктора Promise есть метод all, который, получая массив обещаний, возвращает обещание, которое ждёт завершения всех указанных в массиве обещаний. Затем он выдаёт успешный результат и возвращает массив с результатами. Если какие-то из обещаний в массиве завершились неудачно, общее обещание также возвращает неудачу (со значением неудавшегося обещания из массива).
Попробуйте сделать что-либо подобное, написав функцию all.
Заметьте, что после завершения обещания (когда оно либо завершилось успешно, либо с ошибкой), оно не может заново выдать ошибку или успех, и дальнейшие вызовы функции игнорируются. Это может упростить обработку ошибок в вашем обещании.
Ну, мы дошли до того, что я потерял счет.
Говорят, PUT и DELETE . Я слышал только о POST и GET и никогда не видел, чтобы что-то вроде $_PUT или $_DELETE проходило мимо любого кода PHP, который я когда-либо просматривал.
Мой вопрос
Для чего нужны эти методы (PUT) и (DELETE), и если их можно использовать в PHP, как я могу это сделать.
Примечание. Я знаю, что на самом деле это не проблема, но я всегда хватаюсь за возможность научиться, если вижу ее, и очень хотел бы научиться использовать эти методы в PHP, если это возможно.
Что это за методы (PUT) и (DELETE) для .
Протокол в основном говорит следующее:
используйте GET , когда вам нужно получить доступ к ресурсу и получить данные , и вам не нужно изменять или изменять состояние этих данных.
используйте HEAD , когда вам нужно получить доступ к ресурсу и получить только заголовки из ответа , без каких-либо данных ресурса.
используйте PUT , когда вам нужно заменить состояние некоторых данных, уже существующих в этой системе.
используйте DELETE , когда вам нужно удалить ресурс (относительно отправленного вами URI) в этой системе.
используйте OPTIONS , когда вам нужно получить параметры связи от ресурса, поэтому для проверки разрешенных методов для этого ресурса . Бывший. мы используем его для запросов CORS и правил разрешений.
Вы можете прочитать об оставшихся двух методах в этом документе, извините, я никогда его не использовал.
По сути, протокол - это набор правил, которые вы должны использовать в своем приложении для его соблюдения.
. и если их можно использовать в PHP, как бы я это сделал.
В приложении php вы можете узнать, какой метод использовался, просмотрев суперглобальный массив $_SERVER и проверив значение поля REQUEST_METHOD .
Итак, из вашего php-приложения вы теперь можете распознать, является ли это запросом DELETE или PUT, например. $_SERVER['REQUEST_METHOD'] === 'DELETE' или $_SERVER['REQUEST_METHOD'] === 'PUT' .
* Также имейте в виду, что некоторые приложения, работающие с браузерами, которые не поддерживают методы PUT или DELETE, используют следующий трюк, скрытое поле из html-формы с глаголом, указанным в его атрибуте value, например :
- МЕТОД
- Uri ресурса
- Заголовки запроса, такие как User-Agent, Host, Content-Length и т. Д.
- (Необязательный текст запроса)
Теперь, хотя вы можете получать данные из запросов POST и GET с соответствующими глобальными объектами ( $_GET , $_POST ), в случае запросов PUT и DELETE PHP не предоставляет эти глобальные объекты быстрого доступа; Но вы можете использовать значение $_SERVER['REQUEST_METHOD'] для проверки метода в запросе и, соответственно, обработки вашей логики.
Итак запрос PUT будет выглядеть так:
И вы можете получить доступ к этим данным в PHP, прочитав поток php://input , например. с чем-то вроде:
и запрос DELETE будет выглядеть так:
И снова вы можете построить свою логику после проверки метода:
Обратите внимание, что запрос DELETE не имеет тела, и обратите особое внимание на код состояния ответа (например, если вы получили запрос PUT и обновили этот ресурс без ошибок, вы должны вернуть статус 204 -No content- ) .
Что это за методы (PUT) и (DELETE)
Вкратце и несколько упрощая: PUT предназначен для загрузки файла по URL-адресу, а DELETE - для удаления файла по URL-адресу.
никогда не видел ничего подобного $_PUT или $_DELETE ни в одном PHP-коде, который я когда-либо просматривал
$_POST и $_GET ужасно названы суперглобалами. $_POST для данных, извлеченных из тела запроса. $_GET для данных, извлеченных из URL. Нет ничего, что строго связывало бы данные в любом из этих мест (особенно URL-адрес) с конкретным методом запроса.
Запросы DELETE заботятся только о пути URL, поэтому нет данных для анализа.
Запросы PUT обычно заботятся обо всем теле запроса (а не о его разобранной версии), к которому вы можете получить доступ с помощью file_get_contents('php://input'); .
если и возможно использовать их в PHP, как бы я это сделал.
Вам нужно будет сопоставить URL-адрес с PHP-скриптом (например, с помощью перезаписи URL-адреса), протестировать метод запроса, отработать какой URL-адрес вы на самом деле имел дело , а затем напишите код для выполнения соответствующего действия.
Чтобы добавить новый элемент:
Для обновления или редактирования:
Чтобы удалить существующий ресурс:
Есть много доступных библиотек, которые могут сделать это за вас.
Названия PHP $_GET и $_POST плохие. $_GET используется для доступа к значениям параметров строки запроса, а $_POST позволяет получить доступ к телу запроса.
Использование параметров строки запроса не ограничивается запросами GET, и другие типы запросов, помимо POST, могут иметь тело запроса.
Если вы хотите узнать, какой глагол используется для запроса страницы, используйте $_SERVER['REQUEST_METHOD'] .
Эта статья — одна из обещанных коротких заметок по ходу цикла статей Автоматизация Для Самых Маленьких.
Поскольку основным способом взаимодействия с IPAM-системой будет RESTful API, я решил рассказать о нём отдельно.
Воздаю хвалы архитекторам современного мира — у нас есть стандартизированные интерфейсы. Да их много — это минус, но они есть — это плюс.
Эти интерфейсы взаимодействия обрели имя API — Application Programming Interface.
Одним из таких интерфейсов является RESTful API, который и используется для работы с NetBox.
Если очень просто, то API даёт клиенту набор инструментов, через которые тот может управлять сервером. А клиентом может выступать по сути что угодно: веб-браузер, командная консоль, разработанное производителем приложение, или вообще любое другое приложение, у которого есть доступ к API.
Например, в случае NetBox, добавить новое устройство в него можно следующими способами: через веб-браузер, отправив curl'ом запрос в консоли, использовать Postman, обратиться к библиотеке requests в питоне, воспользоваться SDK pynetbox или перейти в Swagger.
Таким образом, один раз написав единый интерфейс, производитель навсегда освобождает себя от необходимости с каждым новым клиентом договариваться как его подключать (хотя, это самую малость лукавство).
Ниже я дам очень упрощённое описание того, что такое REST.
Начнём с того, что RESTful API — это именно интерфейс взаимодействия, основанный на REST, в то время как сам REST (REpresentational State Transfer) — это набор ограничений, используемых для создания WEB-сервисов.
О каких именно ограничениях идёт речь, можно почитать в главе 5 диссертации Роя Филдинга Architectural Styles and the Design of Network-based Software Architectures. Мне же позвольте привести только три наиболее значимых (с моей точки зрения) из них:
- В REST-архитектуре используется модель взаимодействия Клиент-Сервер.
- Каждый REST-запрос содержит всю информацию, необходимую для его выполнения. То есть сервер не должен помнить ничего о предыдущих запросах клиента, что, как известно, характеризуется словом Stateless — не храним информацию о состоянии.
- Единый интерфейс. Реализация приложения отделена от сервиса, который оно предоставляет. То есть пользователь знает, что оно делает и как с ним взаимодействовать, но как именно оно это делает не имеет значения. При изменении приложения, интерфейс остаётся прежним, и клиентам не нужно подстраиваться.
А API, который предоставляют RESTful WEB-сервисы, называется RESTful API.
Адрес назначения (или иным словом — объект, или ещё иным — эндпоинт) — это привычный нам URI.
Формат передаваемых данных — XML или JSON.
На чтение права не требуются, но если хочется попробовать читать с токеном, то можно воспользоваться этим: API Token: 90a22967d0bc4bdcd8ca47ec490bbf0b0cb2d9c8.
Давайте интереса ради сделаем один запрос:
Или чуть более академически: GET возвращает типизированный объект devices, являющийся параметром объекта DCIM.
Этот запрос можете выполнить и вы — просто скопируйте себе в терминал.
URL, к которому мы обращаемся в запросе, называется Endpoint. В некотором смысле это конечный объект, с которым мы будем взаимодействовать.
Например, в случае netbox'а список всех endpoint'ов можно получить тут.
Вот что мы получим в ответ:
Это JSON (как мы и просили), описывающий device с ID 1: как называется, с какой ролью, какой модели, где стоит итд.
Так будет выглядеть ответ:
А теперь разберёмся, что же мы натворили.
Стартовая строка
Заголовки
В них указано, что
В них указано, что
- Тип сервера: nginx на Ubuntu,
- Время формирования ответа,
- Формат данных в ответе: JSON
- Длина данных в ответе: 1638 байтов
- Соединение не нужно закрывать — ещё будут данные.
Тело используется для передачи собственно данных.
Между заголовками и телом должна быть как минимум одна пустая строка.
А вот например, при POST уже и в запросе будет тело. Давайте о методах и поговорим теперь.
Давайте на примере NetBox разберёмся с каждым из них.
Это метод для получения информации.
Так, например, мы забираем список устройств:
Метод GET безопасный (safe), поскольку не меняет данные, а только запрашивает.
Он идемпотентный с той точки зрения, что один и тот же запрос всегда возвращает одинаковый результат (до тех пор, пока сами данные не поменялись).
Тело возвращается в формате JSON или XML.
Давайте ещё пару примеров. Теперь мы запросим информацию по конкретному устройству по его имени.
Если нужно задать пару условий, то запрос будет выглядеть так:
Здесь мы запросили все устройства с ролью leaf, расположенные на сайте mlg.
То есть два условия отделяются друг от друга знаком "&".
Из любопытного и приятного — если через "&" задать два условия с одним именем, то между ними будет на самом деле не логическое «И», а логическое «ИЛИ».
То есть вот такой запрос и в самом деле вернёт два объекта: mlg-leaf-0 и mlg-spine-0
Попробуем обратиться к несуществующему URL.
POST используется для создания нового объекта в наборе объектов. Или более сложным языком: для создания нового подчинённого ресурса.
То есть, если есть набор devices, то POST позволяет создать новый объект device внутри devices.
Выберем тот же Endpoint и с помощью POST создадим новое устройство.
Здесь уже появляется заголовок Authorization, содержащий токен, который авторизует запрос на запись, а после директивы -d расположен JSON с параметрами создаваемого устройства:
Теперь новым запросом с методом GET можно его увидеть в выдаче:
POST, очевидно, не является ни безопасным, ни идемпотентным — он наверняка меняет данные, и дважды выполненный запрос приведёт или к созданию второго такого же объекта, или к ошибке.
Это метод для изменения существующего объекта. Endpoint для PUT выглядит иначе, чем для POST — в нём теперь содержится конкретный объект.
PUT может возвращать коды 201 или 200.
Важный момент с этим методом: нужно передавать все обязательные атрибуты, поскольку PUT замещает собой старый объект.
Поэтому, если например, просто попытаться добавить атрибут asset_tag нашему новому устройству, то получим ошибку:
Но если добавить недостающие поля, то всё сработает:
Этот метод используется для частичного изменения ресурса.
WAT? Спросите вы, а как же PUT?
PUT — изначально существовавший в стандарте метод, предполагающий полную замену изменяемого объекта. Соответственно в методе PUT, как я и писал выше, придётся указать даже те атрибуты объекта, которые не меняются.
А PATCH был добавлен позже и позволяет указать только те атрибуты, которые действительно меняются.
Здесь также в URL указан ID устройства, но для изменения только один атрибут serial.
Очевидно, удаляет объект.
Метод DELETE идемпотентен с той точки зрения, что повторно выполненный запрос уже ничего не меняет в списке ресурсов (но вернёт код 404 (NOT FOUND).
Curl — это, конечно, очень удобно для доблестных воинов CLI, но есть инструменты получше.
Postman
Postman позволяет в графическом интерфейсе формировать запросы, выбирая методы, заголовки, тело, и отображает результат в удобочитаемом виде.
Кроме того запросы и URI можно сохранять и возвращаться к ним позже.
Так мы можем сделать GET:
Здесь указан Token в GET только для примера.
Postman служит только для работы с RESTful API.
Один из приятных бонусов специфицированного API в том, что вы можете в Postman импортировать все эндпоинты и их методы как коллекцию.
Далее, всё, что только можно, вы найдёте в коллекциях.
Python+requests
Но даже через Postman вы, скорее всего, не будете управлять своими Production-системами. Наверняка, у вас будут внешние приложения, которые захотят без вашего участия взаимодействовать с ними.
Снова добавим новое устройство:
Python+NetBox SDK
В случае NetBox есть также Python SDK — Pynetbox, который представляет все Endpoint'ы NetBox в виде объекта и его атрибутов, делая за вас всю грязную работу по формированию URI и парсингу ответа, хотя и не бесплатно, конечно.
Например, сделаем то же, что и выше, использую pynetbox.
Список всех устройств:
Добавить новое устройство:
SWAGGER
За что ещё стоит поблагодарить ушедшее десятилетие, так это за спецификации API. Если вы перейдёте по этому пути, то попадёте в Swagger UI — документацию по API Netbox.
На этой странице перечислены все Endpoint'ы, методы работы с ними, возможные параметры и атрибуты и указано, какие из них обязательны. Кроме того описаны ожидаемые ответы.
На этой же странице можно выполнять интерактивные запросы, кликнув на Try it out.
По какой-от причине swagger в качестве Base URL берёт имя сервера без порта, поэтому функция Try it out не работает в моих примерах со Swagger'ом. Но вы можете попробовать это на собственной инсталляции.
При нажатии на Execute Swagger UI сформирует строку curl, с помощью которой можно аналогичный запрос сделать из командной строки.
В Swagger UI можно даже создать объект:
Для этого достаточно быть авторизованным пользователем, обладающим нужными правами.
То, что мы видим на этой странице — это Swagger UI — документация, сгенерированная на основе спецификации API.
С трендами на микросервисную архитектуру всё более важным становится иметь стандартизированный API для взаимодействия между компонентами, эндпоинты и методы которого легко определить как человеку, так и приложению, не роясь в исходном коде или PDF-документации.
Поэтому разработчики сегодня всё чаще следуют парадигме API First, когда сначала задумываются об API, а уже потом о реализации.
В этом дизайне сначала специфицируется API, а затем из него генерируются документация, клиентское приложение, серверная часть и необходимы тесты.
Swagger — это фреймворк и язык спецификации (который ныне переименован в OpenAPI 2.0), позволяющие реализовать эту задачу.
Углубляться в него я не буду.
За бо́льшими деталями сюда:
Существует и такая, да. Не всё в том мире 2000-го года так уже радужно.
Не являясь экспертом, не берусь предметно раскрывать вопрос, но дам ссылку на небесспорную статью на Хабре.
Альтернативным интерфейсом взаимодействия компонентов системы сегодня является gRPC. Ему же пророчат большое будущее на ниве новых подходов к работе с сетевым оборудованием. Но о нём мы поговорим когда-то в будущем, когда придёт его черёд.
Можно также взглянуть на многообещающий GraphQL, но нам опять же нет нужды с ним работать пока, поэтому остаётся на самостоятельное изучение.
Важно
Токен a9aae70d65c928a554f9a038b9d4703a1583594f был использован только в демонстрационных целях и больше не работает.
Прямое указание токенов в коде программы недопустимо и сделано здесь мной только в интересах упрощения примеров.
Спецификация явно не запрещает и не препятствует этому, поэтому я бы сказал, что это разрешено.
If a DELETE request includes an entity body, the body is ignored [. ]
@ Джейсон Определенно. Вы также можете использовать настраиваемые заголовки для передачи дополнительных данных, но почему бы не использовать тело запроса. - Tomalak 06 янв.
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.
последняя неутвержденная версия спецификации отменяет это требование. Последней утвержденной версией по-прежнему является RFC2616, указанный выше. - BishopZ 25 авг.
Какая версия? Версия 20 по-прежнему имеет ту же формулировку, что и версия 19, которую я привел выше: «Тела в запросах DELETE не имеют определенной семантики. Обратите внимание, что отправка тела по запросу DELETE может привести к тому, что некоторые существующие реализации отклонят запрос». - grzes 03 окт.
Версия 26 предполагает, что вы можете разрешить тело: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. Итак, она идет с предупреждением об обратной совместимости, она предполагает, что следующий стандарт будет говорить: «Ага! DELETE может иметь тело`. - Pure.Krome 14 июня '14 в 06:33
В разделе 4.3.5 RFC 7231 доработан язык версии 26 с расширением A payload within a DELETE request message has no defined semantics . Итак, тело разрешено. - mndrix 29 мар.
Тело разрешено, но не должно иметь отношения к запросу. В этом нет никакого смысла. - Evert 17 фев '19 в 16:29
Некоторые версии Tomcat и Jetty игнорируют тело объекта, если оно присутствует. Что может быть неприятно, если вы намеревались его получить.
Google App Engine создает и передает пустую сущность по умолчанию вместо тела запроса. - Oliver Hausler 20 окт.
Одна из причин использовать тело в запросе на удаление - это оптимистичный контроль параллелизма.
Вы читаете версию 1 записи.
Ваш коллега читает версию 1 записи.
Ваш коллега изменяет запись и обновляет базу данных, в результате чего версия обновляется до 2:
Вы пытаетесь удалить запись:
Вы должны получить исключение оптимистичной блокировки. Перечитайте запись, убедитесь, что она важна, и, возможно, не удаляйте ее.
Еще одна причина его использования - удаление нескольких записей за раз (например, сетка с флажками для выбора строк).
Это работает в Tomcat (7.0.52) и Spring MVC (4.05), возможно, и в более ранних версиях:
Как это ЯВНО плохо с ним обращаются, когда спецификация не запрещает тело в DELETE? - Neil McGuigan 15 авг.
Спецификация не «говорит об этом», а просто говорит, что тело конкретно не определено. Если он не определен, и вы хотите его игнорировать, круто . продолжайте и игнорируйте его. Но полный отказ от запроса кажется чрезмерным и ненужным. - Ben Fried 27 фев '18 в 17:16
Не полагайтесь на неопределенное поведение. Это довольно распространенная передовая практика. - Evert 17 фев '19 в 19:07
Мне кажется, что RFC 2616 не определяет этого.
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.c
Есть ли какие-то функции в Chrome и / или Firefox, которых мне не хватает?
Сделайте вызов AJAX в консоли Chrome. Расширение не требуется. Это хороший способ делать запросы POST без необходимости захватывать файлы cookie аутентификации. $.post('/resource/path/') - FearlessFuture 15 марта '17 в 16: 512017-03-15 16:51
В то время как надстройка необходима, окончательный вариант - полная ерунда. Он просил функциональности в Chrome или Firefox, или, если ему нужен плагин. Дело не в том, что для этого может потребоваться указанный или неуказанный плагин - Shayne 16 июн.
Для такого рода вещей я делаю приложение Chrome под названием Postman . Все остальные расширения казались немного устаревшими, поэтому я сделал свои собственные. Он также имеет множество других функций, которые были полезны для документирования нашего собственного API здесь.
Postman теперь также имеет собственные приложения (т.е. автономные) для Windows, Mac и Linux! Сейчас предпочтительнее использовать нативные приложения, подробнее читайте здесь .
Не забудьте также установить плагин-перехватчик Postman, если вы хотите использовать файлы cookie вашего браузера, session. - GP cyborg 01 фев в 20:04
Вы разрабатываете отличные инструменты и приложения для разработчика @abhinav Спасибо - dipenparmar12 14 мая в 4:48
Люди могут также найти веб - версию Почтальон здесь . Установка даже не требуется. - Quicksilver 23 июня в 7:44
Инструмент может быть полезен, но стороннее приложение не отвечает на вопрос, который просит сделать это через Chrome или Firefox. - Gloweye 7 июл в 11:30
CURL является удивительным , чтобы делать то , что вы хотите! Это простой, но эффективный инструмент командной строки.
Команды тестирования реализации REST:
Я поддерживаю это, хотя это неправильный ответ на вопрос: вместо этого мне нужно было знать это. - Jim Pivarski 07 янв.
У меня это не работает, я не могу использовать одинарные кавычки в OSX с zsh и bash, оболочка переходит в quote> режим. Мне нужно использовать -d "
Да, curl это круто, он почти всегда уже есть в Unix, и он действительно легкий для Windows. Без регистрации и смс! ;) - RAM237 4 окт.
Fire Fox
Эта функция не работает для кого-то еще? При редактировании параметров в поле «Строка запроса» после изменения одного символа он отказывается изменять запрос дальше. Единственный способ сделать это помимо этого - отредактировать весь URL / запрос (что сложно, потому что все они смешаны вместе) - Coldblackice 29 марта '15 в 21: 032015-03-29 21:03
@Coldblackice Не могли бы вы опубликовать снимок экрана или регистратор шагов проблемы? Я могу нормально редактировать строку запроса. Чтобы добавить новую строку запроса, я либо использую & =, либо просто начинаю новую строку. Чтобы отредактировать, измените отдельные k, v или я просто удаляю и начинаю заново. - 0fnt 30 марта '15 в 8: 522015-03-30 11:52
@ dima-lituiev, скриншоты выше для Firefox, и я подтвердил, что он работает в Firefox версии 88.0.1 - youcantexplainthat 21 мая в 15:15
Если вы настаиваете на расширении браузера, то:
Хром :
Firefox :
Последний раз плакат обновлялся 28.06.11 - обновления Firefox означают, что его невозможно запустить - Richard 27 авг.
@akostadinov Я не могу использовать надстройку для тестирования ресурсов в Mozilla, инструмент не отображается (даже после установки и перезапуска) в инструментах разработчика в последней версии firefox. - Ram 18 сен '14 в 7:23
Только что попробовал REST Easy. Не устанавливается на месте: интерфейс слишком утомителен и вынуждает пользователя ограничиваться жесткими вариантами использования. Не подходит для разработки API. - 7heo.tk 09 июля '15 в 11: 202015-07-09 11:20
Вдохновленный Postman для Chrome , я решил написать что-то подобное для Firefox.
REST Easy * - это надстройка Firefox без перезапуска, целью которой является обеспечение максимального контроля над запросами. Надстройка все еще находится в экспериментальном состоянии (она еще даже не проверена Mozilla), но разработка идет неплохо.
@Pacerier: это функция, над которой я сейчас работаю, и я готов примерно на 90%. Надеюсь, он выйдет до конца года. Кажется, есть отставание в получении дополнений, одобренных Mozilla. - Nathan Osman 11 дек.
После более чем месяца ожидания новая версия была одобрена. Прибыла поддержка PUT и DELETE! И за этот месяц я также внес массу других изменений, которые скоро появятся в следующем выпуске. (Надеюсь, на этот раз он будет одобрен раньше.) - Nathan Osman 23 дек.
С формой, просто установите method для "post"
Т.е. создайте себе очень простую страницу для тестирования действий POST .
Для тех, кто не знает, я добавлю: то, что вы указываете как action ресурс, который вы хотите получить (который может включать параметры запроса в стиле GET), и value указывает тело данных POST. Например, action="api/ids?name=John" и value="hello" отправит POST-запрос
У меня он отлично работает - помните, что вы все еще можете использовать с ним отладчик. Панель «Сеть» особенно полезна; он предоставит вам обработанные объекты JSON и страницы ошибок.
Для Firefox также есть неплохое расширение под названием RESTClient:
Возможно, это не связано напрямую с браузерами, но Fiddler - еще одно хорошее программное обеспечение.
Существует хороший простой пример Fetch API здесь :
Некоторые из преимуществ команды fetch действительно драгоценны: она проста, коротка, быстра, доступна и даже в качестве консольной команды она хранится на вашей консоли Chrome и может использоваться позже.
Простота нажатия F12 , напишите команду на вкладке консоли (или нажмите клавишу «вверх», если вы использовали ее раньше), затем нажмите Enter , чтобы увидеть ее в ожидании и вернуть ответ - вот что делает ее действительно полезной для простых тестов POST-запросов.
Конечно, основным недостатком здесь является то, что, в отличие от Postman, он не проходит политику кросс-происхождения, но все же я считаю его очень полезным для тестирования в локальной среде или других средах, где я могу включить CORS вручную.
Читайте также: