Ну конкретно, приводить примеры API — это уже более частная задача. Я же ставил целью объяснить выбор конкретной идеологии\технологии в рамках широко спектра существующих вариантов.
С билетами в театр немного синтетический пример, но поясню. Перед покупкой билета надо убедиться, что место свободно. Если оно свободно, то создается заказ в статусе «неоплачено», который, если его недозаполнить и не оплатить, удалится, скажем, через 10 минут. Кроме того, есть театры, куда билеты продаются без мест. Туда надо проверять вообще наличие свободных мест.
Таким образом, операция предварительного заказа билета на театр без места по сути — создание объекта «заказ» в системе в статусе «неоплачено». Т.е. если я дважды сделаю этот запрос, то дважды будет создан «заказ». Т.е. операция не является идемпотентной, поэтому POST.
А вот для перевода заказа в статус «оплачен» я буду использовать PUT.
А на какой случай необходима подпись параметров? На случай увода авторизационного ключа?
По второй части: отличная идея! Главное, что б было на уровне воткнул — заработало.
Но, к сожалению, партнёр представляет себе межистемное взаимодействие как периодический обмен шифрованными и подписанными письмами :)
С билетами в театр немного синтетический пример, но поясню. Перед покупкой билета надо убедиться, что место свободно. Если оно свободно, то создается заказ в статусе «неоплачено», который, если его недозаполнить и не оплатить, удалится, скажем, через 10 минут. Кроме того, есть театры, куда билеты продаются без мест. Туда надо проверять вообще наличие свободных мест.
Таким образом, операция предварительного заказа билета на театр без места по сути — создание объекта «заказ» в системе в статусе «неоплачено». Т.е. если я дважды сделаю этот запрос, то дважды будет создан «заказ». Т.е. операция не является идемпотентной, поэтому POST.
А вот для перевода заказа в статус «оплачен» я буду использовать PUT.