Самый чистый RESTful дизайн для чисто «экшн» звонков?

Question

Я торчу пальцем в воду RESTful и просто не могу найти «удовлетворительное» решение для того, как обрабатывать действительно «ориентированные на действия» вызовы службы RESTful? Мой недуг можно разбить на две части.

1) Транзакционные вызовы: я понимаю идею наличия ActionTransactor, когда вы также получаете ресурс с публикацией, обновляете параметры и затем фиксируете с помощью PUT (как описано повсеместно и в книге Orilly RESTful Web-сервисов ) .. Но я борюсь с идеей сохранения навсегда URL-адресов с состояниями. Если нам действительно честно не нужно хранить транзакции навсегда, можем ли мы уничтожить URI ресурса? действительно ли URI должны быть perminate или они могут быть транзиантными URI, срок действия которых истекает

2) Нетранзакционные вызовы: это могут быть вызовы для выполнения некоторого рабочего процесса, который охватывает несколько ресурсов, но с тех пор ресурс просто не создается. Примером может быть повторное генерирование некоторого вычисленного и кэшированного значения типа ans, например большого агрегирования или переиндексация блога или какое-то подобное «чисто» действие.

В любом случае, мне любопытно узнать мнение сообщества по этому поводу ... До сих пор я читал, что «Перегрузка поста» - это самый чистый способ справиться с частью 2. Но против такого подхода есть столько же аргументов, сколько Что ж. И (для меня) это не самодокументирование, хотя я и был одной из ключевых целей разработки API-интерфейсов RESTful.

Answer 1

1). Хранение URI с состояниями навсегда: рассмотрим любой веб-сайт. У него есть несколько страниц. Некоторые удаляются, и мы получаем 404, когда пытаемся получить к ним доступ. Рассмотрим базу данных, скажем, с клиентами в ней. У нашего средства доступа RESTful есть URI, такие как http://myserver/customer/12345 - если клиент был заменен, то мы можем вернуть 404. Мне это кажется вполне разумным. URI являются временными в том, что они могут быть синтаксически действительными, но система имеет четко определенное поведение, если ресурс теперь устарел. Я считаю, что обработка ошибок для остальных услуг является важным фактором. Я обсуждаю это здесь

2). Действия, которые не совсем соответствуют модели REST: я не уверен, является ли PUT или POST наиболее подходящим методом. Как насчет идеи, что ресурс запрос сделать что-то? Таким образом, мы могли бы положить / POST до

http://myserver/request/cacheupdate

Это может вернуть полезную нагрузку запроса, включая уникальный идентификатор (точно так же, как создание клиента может вернуть информацию о клиенте, включая сгенерированный системой идентификатор). Затем ресурс запроса можно использовать для определения того, завершился ли запрос, используя уникальный идентификатор.

http://myserver/request/12345

Это позволяет нам отслеживать состояние длительных запросов.