-
tools.ietf.org
После множества статей про REST у меня сложилось стойкое déjà vu, хотя, наверное, имеет право на жизнь.
-
If a server implements version control for a resource, and the resource version is incorrectly specified by a client for an operation that modifies the resource, the server SHOULD indicate this with a 412 Precondition Failed status code.
Хмм. А мы у себя через Accept: и всякие там vnd.projectname.web-2.0+json (или как там оно) делаем версионинг, и в случае неподдержки API возвращаем 415 ошибку "media type not supported", а не 412./1 · Reply -
@kb, Мы еще не доросли до проблем версионирования, но пока идея такая: документация версионируется ресурсом. Версионирование API подумываю сделать через схему данных, в sdk определяется вся рутина по работе с версиями; если клиент хочет поменять версию, то запускай migration-скрипт на свою базу и повышает/понижает версию протокола. Тут правда момент, что клиентам выдается своя база CouchDB в полное распоряжение.
-
@Laz, а вообще, ты прав:
w3.org
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. -
@Laz, собственно версия ресурса и описывает это состояние. если честно, у меня сложилась некая каша, можно я разделю точки зрения?
есть версионирование веткой: грубо и топорно {version}{collection}/{id}/{action}
есть версионирование медиа типом: таким образом можно варьировать возвращаемую схему данных в зависимости от указанной версии и определять доступные для указанной версии операции
есть версионирование ресурса: оно определяет состояние данных ресурса и эта версия в идеале должна хорошо лечь в Etag
из такой картины я вот понял, что моя попытка версионировать схему данных через сами данные просто глупа и неправильна, благо все только на стадии разработки дизайна(: -
@Kxepal, Хмм, не знал про Etag, спасибо. Получается, что поле _ver, предложенное в сабжевом драфте, не нужно. А для версионирования API мне более правильным показалось использование параметров медиа типа — application/vnd.example.type; v=1 — то есть вариация второго варианта. Указывать версию в урле, по-моему, как-то не очень красиво.
-
@Laz, в зависимости от контекста. если ты контролируешь конкурентные обновления ресурса, то _rev тебе очень нужна для определения кто победил, а кто опоздал и создает конфликтную ситуацию — собственно так устроена MVCC и так работает CouchDB, при этом так же используется как значение Etag, поскольку однозначно определяет состояние ресурса. А версия в урле да, но, например, для GET-only ветки ресурсов такое решение смотрится достаточно красиво и просто.
-
@Kxepal, Когда клиент обновляет ресурс, в заголовке If-Match он указывает, какую версию ресурса он видел последней. Если кто-то успел изменить ресурс до него, то есть версия ресурса не совпадает с If-Match, сервер должен ответить кодом 412 (это из rfc2616#14.24, таки странно, почему не 409). Честно говоря, мне до версионирования ресурсов ещё далеко, так что я об этом пока не задумывался, возможно, имеет смысл передавать версию и в заголовке, и в представлении. До версионирования мне API ещё дальше, но я уже начитался статей REST-гуру, которые пишут, что версия в урле не комильфо. Хотя, согласен, это упрощает жизнь клиентам.