Вопрос о REST: ПОМЕСТИТЬ одно представление, ПОЛУЧИТЬ другое?
Короткая версия вопроса:
Действительно "ДОБИРАЕТСЯ" в конкретном URI, должен соответствовать тому, что было "ПОМЕЩЕНО" в тот URI?
Я думаю, нет. Вот то, почему:
Учитывая, что ресурс является абстрактной вещью, которая теоретически непостижима клиентом, когда мы делаем ПОМЕЩЕННЫЙ, мы должны только отправлять представление. На основе расчесывания по RFC2616 не кажется совершенно указанным относительно того, что это означает для ресурса, который имеет многих (потенциально бесконечный?) представления, но вот мои мысли; скажите мне, если Вы соглашаетесь:
Мое ожидание состоит в том что, если я ПОМЕСТИЛ представление ресурсу, все другие представления ресурса в том, что URI должен быть сохранен последовательным (потенциально обновленный) по мере необходимости. Другими словами, Вы говорите, что ресурс "использует это представление для переопределения себя".
Таким образом я должен смочь сделать это:
ПОМЕЩЕННЫЙ/resources/foo/myvacation
Тип контента: image/jpg
...
И добейтесь этого:
ПОЛУЧИТЕ/resources/foo/myvacation
Примите: image/png
...
и получите обновленную версию myvacation в другом формате (предполагающий, что сервер знает, как сделать это). Экстраполируя от этого, это составное атомарное "изображение + метаданные", ПОМЕЩЕННЫЕ, должны также быть законными:
ПОМЕЩЕННЫЙ/resources/foo/myvacation
Тип контента: multipart/form-dataДовольное расположение: данные формы; назовите = "документ"
Тип контента: image/jpg
[..]
Довольное расположение: данные формы; назовите = "iptc"
Тип контента: application/iptc
[..]
Довольное расположение: данные формы; назовите = "exif"
Тип контента: application/exif
[..]
И затем, потому что согласование содержания серверной стороны (раздел RFC2616 12.1) может произойти на основе примерно чего-либо, мы можем принять значение по умолчанию к содержанию "документа" для этого:
ПОЛУЧИТЕ/resources/foo/myvacation
Тип контента: image/jpg
[..]
или если Вы верите, как я делаю тот раздел RFC 2396 3.4 "Компонент запроса является строкой информации, которая будет интерпретироваться ресурсом". средства, что URI со строкой запроса называет тот же ресурс URI без строки запроса (и изоморфно только с данными заявления отправки к ресурсу), затем это должно также быть законно:
ПОЛУЧИТЬ/resources/foo/myvacation? content=exif
Тип контента: application/exif
[..]
В описании PUT говорится:
ПОМЕЩЕННЫЙ метод запрашивает, чтобы вложенный объект был сохранен под предоставленным URI запроса.
Мне это - справедливо анти-REST, если Вы не читаете его очень либеральным способом. Моя интерпретация является "ПОМЕЩЕННЫМИ запросами метода, что ресурс создается или обновляется в предоставленном URI запроса на основе представления вложенного объекта".
Позже, мы добираемся:
Принципиальное различие между POST и ПОМЕЩЕННЫМИ запросами отражается в другом значении URI запроса. URI в запросе POST определяет ресурс, который обработает вложенный объект. Тот ресурс мог бы быть принимающим данные процессом, шлюзом к некоторому другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в ПОМЕЩЕННОМ запросе отождествляет объект, включенный с запросом - агент пользователя знает то, что предназначается URI, и сервер не ДОЛЖЕН пытаться применить запрос к некоторому другому ресурсу.
Мы должны так же считать это творчески, но ключевые биты здесь, "знает то, что предназначается URI", и "применяют запрос".
Так, мне представление, возвращенное, Достигает данный URI, должно не обязательно быть то же представление, которое было ПОМЕЩЕНО в данный URI, это просто должно быть последовательно.
TRUE или FALSE?
4 ответа
Я согласен с другими ответами, что ресурс, который вы ПОЛУЧАЕТЕ, не обязательно должен быть таким же, как тот, который вы ПОЛУЧАЕТЕ позже. Я хотел бы добавить немного своего опыта к этому вопросу в этой области.
Вы должны быть очень осторожны, полагаясь на согласование содержания. Это очень сложно сделать правильно, и если вы не сделаете это правильно, это приведет к неприятным проблемам с пользователем. Давайте рассмотрим пример, основанный на изображениях ...
Если Алиса ПОСТАВИТ изображение в необработанном формате, то Боб может ПОЛУЧИТЬ изображение как jpeg (через преобразование raw-> jpeg на стороне сервера), а Алиса может ПОЛУЧИТЬ изображение в необработанном формате; Нет проблем. Однако, если Боб ПОСТАВЛЯЕТ jpeg, то нет возможности вернуться к исходному формату для Алисы. В случае фотографий с отпуска отсутствие симметричных преобразований может не иметь большого значения, но в медицинских изображениях это будет.
Другая область, в которой вас беспокоит отсутствие симметричных преобразований, - это представления, в которых у одного есть схема, а у другого нет. В этом случае на стороне сервера вы в конечном итоге соглашаетесь, как преобразовывать их. Но вы сталкиваетесь с большими проблемами, когда имеете дело с документами со схемами, которые со временем меняются и находятся вне вашего контроля. Каждый раз, когда схема изменяется, вам необходимо обновить все свои преобразования для новой формы схемы, при этом поддерживая ресурсы с использованием старой схемы. Согласование содержания быстро становится больше проблем, чем оно того стоит, за исключением нескольких ограниченных обстоятельств. Одна из областей, в которой им можно управлять, - это если вы полностью контролируете представление ресурса и его базовую схему.
Если вы трансформируете, то имеет смысл, что вы PUT не то, что вы GET, так что я не понимаю, почему это проблема.
Но, если вы PUT пользователь с определенной информацией, то при использовании GET он должен получить эту фотографию, точно так же, как и при размещении моей 4-й фотографии в отпуске, когда я звоню GET я ожидаю, что эта фотография, но она может быть преобразована путем преобразования в другой формат, или иметь другие преобразования, но, если я получу 5-ю фотографию вместо этого, то это будет проблемой.
Основываясь на том, что согласование содержимого может возвращать различные представления из одного и того же URI, я вполне уверен, что то, что вы PUT, не обязательно должно быть тем же самым, что вы получаете.
.Ваши предположения верны. GET не обязательно должен возвращать то же представление , что и то, что вы PUT, но это должен быть тот же ресурс .
В настоящее время я работаю над веб-приложением, которое вернет любой ресурс в виде XHTML, JSON, или пользовательского XML диалекта, в зависимости от того, что вы запрашиваете в заголовках согласования содержимого. Таким образом, браузер будет видеть HTML по умолчанию. Другие HTTP клиенты, включая XMLHttpRequest, могут получить JSON, и так далее. Все они являются представлениями одного и того же ресурса в одном URI.
Аналогично, наше приложение будет принимать PUT или POST в любом из поддерживаемых форматов (с учетом семантики конкретного ресурса или коллекции, о которой идет речь)
.