Вопрос REST: ПОСТАВИТЬ одно представление, ПОЛУЧИТЬ другое?

Question

Краткая версия вопроса:
Должен ли "GET" в конкретном URI совпадать с тем, что было "PUT" с этим URI?

Я думаю, что нет. И вот почему:

Учитывая, что ресурс является абстрактной вещью, которую клиент теоретически не может понять, когда мы выполняем PUT, мы должны только отправлять представление. Основываясь на расчесывании по RFC2616, не совсем ясно, что это означает для ресурса, который имеет много (потенциально бесконечных?) Представлений, но вот мои мысли; пожалуйста, скажите мне, если вы согласны:

Мое ожидание состоит в том, что если я помещаю представление в ресурс, все другие представления ресурса в этом URI должны поддерживаться согласованными (потенциально обновленными) по мере необходимости. Другими словами, вы говорите ресурсу «используйте это представление, чтобы переопределить себя».

Таким образом, я должен быть в состоянии сделать это:

PUT / resources / foo / myvacation
Тип контента: изображение / jpg
...

И следите за этим:

GET / resources / foo / myvacation
Принять: изображение / PNG
...

и получите обновленную версию myvacation в другом формате (при условии, что сервер знает, как это сделать). Экстраполируя это, этот составной атомарный PUT «изображение + метаданные» также должен быть законным:

PUT / resources / foo / myvacation
Тип содержимого: multipart / form-data

Содержание-расположение: форма-данные; имя = "документ"
Тип контента: изображение / jpg
[..]
Содержание-расположение: форма-данные; Name = "IPTC"
Тип контента: приложение / iptc
[..]
Содержание-расположение: форма-данные; Name = "" * Exif 1040 * Тип контента: приложение / exif
[..]

И затем, поскольку согласование содержимого на стороне сервера (раздел 12.1 RFC2616) может происходить практически на основе чего угодно, для этого мы можем по умолчанию использовать содержимое документа:

GET / resources / foo / myvacation
Тип контента: изображение / jpg
[..]

или если вы верите, как я, то в разделе 3.4 RFC 2396 «Компонент запроса представляет собой строку информации, которая должна интерпретироваться ресурсом». означает, что URI со строкой запроса ссылается на тот же ресурс, что и URI без строки запроса (и изоморфен только при отправке данных application / x-form-urlencoded на ресурс), тогда это также должно быть допустимым:

GET / resources / foo / myvacation? Content = exif
Тип контента: приложение / exif
[..]

В описании PUT говорится:

Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Request-URI.

Для меня это довольно анти-REST, если вы не читаете его очень либерально. Моя интерпретация такова: «Метод PUT запрашивает создание или обновление ресурса по предоставленному Request-URI на основе представления вложенного объекта».

Позже мы получим:

Принципиальное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать вложенный объект. Этот ресурс может быть процессом приема данных, шлюзом к другому протоколу или отдельным объектом, принимающим аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный в запросе - пользовательский агент знает, для чего предназначен URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу.

Нам нужно творчески прочесть это аналогичным образом, но ключевые биты здесь: «знает, для чего предназначен URI» и «применить запрос».

Итак, для меня представление, возвращаемое GET для данного URI, не обязательно должно быть тем же представлением, которое было PUT для данного URI, оно просто должно быть согласованным.

Правда или ложь?

Answer 1

Исходя из того, что согласование контента может возвращать разные представления из одного и того же URI, я совершенно уверен, что то, что вы PUT не обязательно должно совпадать с тем, что вы получаете.

Answer 2

Ваши предположения верны. GET не обязательно должен возвращать то же представление , что и PUT, но это должен быть тот же ресурс .

В настоящее время я работаю над веб-приложением, которое будет возвращать любой ресурс в виде XHTML, JSON или пользовательского XML-диалекта, в зависимости от того, что вы запрашиваете в заголовках согласования контента. Таким образом, браузер будет видеть HTML по умолчанию. Другие клиенты HTTP, включая XMLHttpRequest, могут получить JSON и т. Д. Все они представляют один и тот же ресурс в одном и том же URI.

Аналогично, наше приложение будет принимать PUT или POST в любом из поддерживаемых форматов (в зависимости от семантики конкретного ресурса или рассматриваемой коллекции).

Answer 3

Я согласен с другими ответами, что ресурс, который вы PUT, не обязательно должен совпадать с ресурсом, который вы позже ПОЛУЧАЕТЕ. Я хотел бы добавить свой опыт в этот вопрос в этой области.

Вы должны быть очень осторожны, полагаясь на согласование контента. Это очень сложно сделать правильно, и если вы не понимаете это правильно, это приводит к неприятным проблемам пользователей. Давайте сделаем пример на основе изображений ...

Если Алиса помещает изображение в необработанном формате, то Боб может получить изображение в формате jpeg (через преобразование raw-> jpeg на стороне сервера), а Алиса может получить изображение в необработанном формате; Нет проблем. Однако, если Боб ставит JPEG, то нет никакого способа вернуться к необработанному формату для Алисы. В случае фотографий из отпуска отсутствие симметричных преобразований может не иметь большого значения, но в медицинских изображениях это может быть.

Другая область, где отсутствие симметричных преобразований кусает вас, - это представления, где у одной есть схема, а у другой - нет. В этом случае на стороне сервера вы соглашаетесь с тем, как трансформироваться между ними. Но вы сталкиваетесь с большими проблемами, когда имеете дело с документами со схемами, которые со временем меняются и находятся вне вашего контроля. Каждый раз, когда схема изменяется, вы должны обновлять все свои преобразования для новой формы схемы, в то же время поддерживая ресурсы, использующие старую схему. Переговоры о контенте быстро становятся более неприятными, чем их ценность, за исключением нескольких ограниченных обстоятельств. Одной из областей, где он может быть управляемым, является полный контроль над представлением ресурса и его базовой схемой. Еще одна область, если форматы ресурсов являются стандартами, и можно проводить симметричные преобразования между различными форматами.

Answer 4

Если вы трансформируетесь, тогда будет иметь смысл, что то, что вы PUT, не то, что вы GET, поэтому я не понимаю, почему это проблема.

Но, если вы PUT пользователь с определенной информацией, то когда вы используете GET, он должен получить этого человека, точно так же, как когда я помещаю свою четвертую фотографию в отпуск, когда я звоню GET, я ожидаю, что фотография, но она может быть преобразована путем преобразования в другой формат или иметь некоторые другие преобразования, но если я получу 5-ую фотографию вместо этого, то это проблема.