Комментарии 19
А нельзя ли немного конкретики? Например опубликуйте часть API, расскажите почему он именно такой.
И объясните пожалуйста, почему у вас операция заказа билета идет через POST, а не через PUT, ведь если через API передается запрос на заказ какого-то конкретного билета (с указанием ряда, места), то получается, что это идемпотентная операция (т.е. состояние системы не зависит от того, сколько раз была выполнена операция), и её следует проводить через PUT.
И объясните пожалуйста, почему у вас операция заказа билета идет через POST, а не через PUT, ведь если через API передается запрос на заказ какого-то конкретного билета (с указанием ряда, места), то получается, что это идемпотентная операция (т.е. состояние системы не зависит от того, сколько раз была выполнена операция), и её следует проводить через PUT.
Ну конкретно, приводить примеры API — это уже более частная задача. Я же ставил целью объяснить выбор конкретной идеологии\технологии в рамках широко спектра существующих вариантов.
С билетами в театр немного синтетический пример, но поясню. Перед покупкой билета надо убедиться, что место свободно. Если оно свободно, то создается заказ в статусе «неоплачено», который, если его недозаполнить и не оплатить, удалится, скажем, через 10 минут. Кроме того, есть театры, куда билеты продаются без мест. Туда надо проверять вообще наличие свободных мест.
Таким образом, операция предварительного заказа билета на театр без места по сути — создание объекта «заказ» в системе в статусе «неоплачено». Т.е. если я дважды сделаю этот запрос, то дважды будет создан «заказ». Т.е. операция не является идемпотентной, поэтому POST.
А вот для перевода заказа в статус «оплачен» я буду использовать PUT.
С билетами в театр немного синтетический пример, но поясню. Перед покупкой билета надо убедиться, что место свободно. Если оно свободно, то создается заказ в статусе «неоплачено», который, если его недозаполнить и не оплатить, удалится, скажем, через 10 минут. Кроме того, есть театры, куда билеты продаются без мест. Туда надо проверять вообще наличие свободных мест.
Таким образом, операция предварительного заказа билета на театр без места по сути — создание объекта «заказ» в системе в статусе «неоплачено». Т.е. если я дважды сделаю этот запрос, то дважды будет создан «заказ». Т.е. операция не является идемпотентной, поэтому POST.
А вот для перевода заказа в статус «оплачен» я буду использовать PUT.
POST к родительскому ресурсу создает новый ресурс.
PUT только для уже существующих.
Не помню где прочитал, но работает хорошо ;)
PUT только для уже существующих.
Не помню где прочитал, но работает хорошо ;)
Проектировщикам REST API весьма рекомендую скачать и прочитать книгу InfoQ Explores: REST. Отличное описание best practices, anti-patterns и немного дискуссий на тему.
Может, кому-то захочется по этой книге сделать статью или несколько на Хабре.
Может, кому-то захочется по этой книге сделать статью или несколько на Хабре.
Одной аутентификации недостаточно. Необходимо подписывать сообщения. Неплохая дискуссия на эту тему есть на O'Reilly: Principles for Standardized REST Authentication.
Спасибо за наводку.
А на какой случай необходима подпись параметров? На случай увода авторизационного ключа?
А на какой случай необходима подпись параметров? На случай увода авторизационного ключа?
Имеет ли смысл подписывать сообщения, если не предполагается, что API будет предоставляться пользователями третьим лицам? В этом случае отдельного аккаунта для робота и базовой авторизации по ssl будет достаточно. По крайней мере, так кажется на первый взгляд.
Спасибо, хорошее руководство по организации api для начинающих.
Я, когда делал api для чата, написал все с нуля, без использования сторонних библиотек и протоколов. И считаю, что это был ценный опыт.
Я, когда делал api для чата, написал все с нуля, без использования сторонних библиотек и протоколов. И считаю, что это был ценный опыт.
Спасибо! Нам очень помогла ваша статья для разработки нашего API. Кому интересно — mytaskhelper.ru/api/index
нельзя ли поподробнее про «пару строчек, и всё готово»? третий день мучаюсь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного о том как организовывать API веб-службы