1 Что такое RESTful
Baidu посмотрел на RESTful, и многие из найденной информации были неясными.После прочтения я не знал, о чем там идет речь, что привело к тому, что многие люди мало что знали о RESTful. Давайте посмотрим на общие объяснения:
(1)богоподобное описаниеREST означает не «отдых», а аббревиатуру Representational State Transfer, то естьПереход состояния уровня представления.
Что, черт возьми, такое «передача состояния уровня представления»?
(2)Описание в тумане
- ОТДЫХ означаетНабор архитектурных ограничений и принципов, если архитектура соответствует ограничениям и принципам REST, она называется архитектурой RESTful.
- RESTful — это архитектурный стиль программного обеспечения, а не стандарт.
Это можно немного понять, но пока туманно.
(3)резюме БогаДавайте посмотрим на краткое изложение фразы Ивони, великого бога Чжиху:
Найдите ресурсы с URL-адресами и опишите операции с HTTP-глаголами (GET, POST, DELETE, PUT).
RESTful — это стиль дизайна веб-службы, что означает, что все по умолчанию, но не обязательно.
2 детали RESTful
2.1 Найдите ресурсы с URL-адресами
Основная часть REST — это ресурсы, так называемый «ресурс» — это конкретная информация в сети, например картинка, фрагмент текста, сервис. Короче говоря, это реальная вещь, и URL-адрес используется для указания на этот ресурс.
Например:
https://api.example.com/users
По этому URL-адресу сразу видно, что это операция над пользовательским ресурсом. В URL-адресе для указания ресурсов используются только существительные, никакие действия не включены. Зачем?
Если вы хотите включить операции, существует как минимум четыре вида добавлений, удалений, изменений и проверок, то один интерфейс в приведенном выше примере должен стать как минимум четырьмя:
https://api.example.com/add_user
https://api.example.com/delete_user
https://api.example.com/update_use
https://api.example.com/get_user
Слишком много, недостаточно лаконично.
2.2 Описать операции с HTTP-глаголами
Как бы вы описали операцию? Ответ заключается в использовании глаголов HTTP.
Глаголы HTTP, многие люди могут быть немного сбиты с толку, когда впервые увидят это.Они не знают, что это такое.На самом деле это GET, POST и другие операции, которые мы используем при запросе веб-страниц. Обычно чаще всего мы используем GET и POST (например, при написании краулеров это в основном эти два), а также обычно используются PUT, PATCH и DELETE.
Операция с ресурсами — это не что иное, как CRUD (добавление, удаление, изменение и поиск).В RESTful каждому HTTP-глаголу соответствует операция CRUD.
- GET: соответствует операции извлечения (операции запроса)
- POST: соответствует операции Create
- УДАЛИТЬ: соответствует операции Удалить
- PUT: соответствует операции обновления.
- PATCH: соответствует операции обновления
2.3 Разница между POST и PUT
Вообще говоря, когда глаголы HTTP соответствуют CRUD, PUT соответствует операции обновления. Но на самом деле PUT также может выполнять операции Create. Разница между ними заключается в следующем:
- URL: POST не нужно указывать отдельному лицу, например интерфейс для добавления пользователя
POST /api/users. URL-адрес PUT должен быть указан для конкретного человека, напримерPUT /api/users/1,если1Если этот пользователь существует, то Обновить, иначе Создать. Это несложно понять.POST это однозначно новое дополнение, и условие where при вставке не нужно, PUT нет, и where не добавляется при обновлении.Друзья кто делал, поднимите пожалуйста руку. Кроме того, при PUT не каждому пользователю нужно строить интерфейс, здесь нужно использовать роутинг, обычно записываемый какPUT /api/users/{id}, что является общим. Маршрутизация здесь не обсуждается. - Идемпотентность: PUT является идемпотентным, а POST неидемпотентным. Об идемпотентности см. Ниже.
2.4 Разница между PATCH и PUT
PATCH является официальным методом http с 2010 года и дополняет PUT. До того, как не было PATCH, для операций обновления используется PUT.В это время обычно в нашем интерфейсе есть логическое правило, например: если значение атрибута объектаnull, то не обновляйте значение свойства (поля), чтобы избежать всех операций перезаписи. Теперь с PATCH это суждение решается, независимо от того, находится ли атрибут в операции PUT.null, все обновляются, в интерфейсе PATCH не-nullобновить. Кроме того, PATCH не является идемпотентным.
2.5 Альтернативный пост
Согласно предложению REST, операция запроса должна использовать метод GET, но на практике это более проблематично, например, запрос статистики отчета должен передавать много параметров, если используется метод GET, интерфейс получает много параметров, а интерфейс уродлив.Обычно он будет инкапсулирован как java-объект, но метод GET не поддерживает передачу параметров объекта, поэтому это очень болезненно;
В этом случае проще всего перейти на метод POST, и многие компании так и поступают. Видно, что REST — это только предложение, а не обязательное ограничение.
Дополнение: Идемпотентность
Идемпотентность — это изначально математическое понятие, поэтому я не буду называть определение, и у меня кружится голова, когда я его вижу.
Позже он был расширен до компьютерной области и описан как:
Любое многократное выполнение операции, метода или службы имеет такое же влияние, как и одно выполнение.
Идемпотентный метод, использующий одни и те же параметры, вызывает его несколько раз и вызывает один раз, и воздействие на систему одинаково. Итак, для идемпотентных методов не нужно беспокоиться о каких-либо изменениях в системе из-за повторного выполнения.
Например, баланс мобильного телефона пользователя X составляет 2 юаня, и он использует Alipay для пополнения своего мобильного телефона на 100 юаней. , и операция повторяется.Несколько раз оператор терял большие деньги. Однако если операция описывается как «установить баланс счета X на 102 доллара США», то операция является идемпотентной. Проще говоря:
- Идемпотентная операция: установить баланс счета X на 102 юаня;
- Неидемпотентная операция: увеличить баланс счета X на 100 юаней.
Примечание: приведенные здесь примеры идемпотентности не являются строгими.Эта статья посвящена не только идемпотентности, поэтому это всего лишь простой пример, и я не буду подробно его обсуждать.
3 Дополнительные сведения о RESTful
3.1 Правила именования
- (1) Все строчные, используйте
_или-линейное подключение.
Например, пример, который я привел выше:
https://api.example.com/add_user
Причина, по которой регистр верблюда не используется, заключается в том, что ранние URI обычно представляют путь к файлу на сервере, а разные серверы имеют разную чувствительность к регистру.Для совместимости с разными серверами предусмотрено, что буквы верхнего и нижнего регистра не могут быть смешанным.
- (2) Для указания ресурсов в URL-адресе используются только существительные, поскольку ядром REST являются ресурсы, а слова, представляющие ресурсы, естественно, являются существительными.
- (3) Ресурсы представлены во множественном числе.
Версия 3.2
Один из способов — добавить номер версии к URL-адресу, например:
https://api.example.com/v1/users
Другой способ — добавить номер версии в поле Accept заголовка HTTP-запроса, например:
Accept: version=1.0
Хотя многие блоги рекомендуют добавлять информацию о версии в заголовок, поскольку ресурсы, представленные разными версиями, все еще одинаковы, разные URL-адреса использовать не следует. Но из того, что я узнал до сих пор, большинство компаний помещают номер версии в URL-адрес, и это рекомендуется делать, это просто и интуитивно понятно.
Примеры номера версии, найденные в Интернете, добавляются в URL-адрес. Но jack_zeng указал, что в этом легко допустить двусмысленность, и люди заблуждаются.v1Это тоже часть ресурса, обычно пишется так:
https://api.example.com/users?api-version=1
3.3 Коды состояния HTTP
По сравнению с объяснением RESTful Айвони другим великим богом на Чжиху, он использовал три предложения для его описания:
- Вы можете увидеть, что вы хотите, посмотрев на URL
- См. http-метод, чтобы узнать, что делать
- Посмотрите на код состояния http, чтобы узнать результат
Первые два предложения имеют то же значение, что и предложение Айвони. Я думаю, что это третье предложение подводит итог очень хорошо.
Существует более 100 кодов состояния http, нам не нужно использовать их все, нам просто нужно понять наиболее часто используемые.
- 200 - ок - все ок
- 201 - ОК - новый ресурс создан
- 204 — ОК — удаление ресурса прошло успешно
- 304 — Без изменений, клиент может использовать кешированные данные
- 400 - Bad Request - Неверный вызов, точная ошибка должна быть описана в полезной нагрузке ошибки.
- 401 — не аутентифицирован, вызов требует аутентификации пользователя
- 403 — Не разрешено, сервер парсит и запрашивает нормально, но вызов отклонен или не разрешен
- 404 — Не найдено, указанный ресурс не существует
- 422 — тело запроса не указано — используется только в том случае, если сервер не может обработать объект, например, изображение не может быть отформатировано или отсутствуют важные поля.
- 500 — Внутренняя ошибка сервера — Стандартная ошибка сервера, разработчики должны стараться избегать этой ошибки.
Использованная литература: