Я бы частично не согласился с предложением Милана о включении запрошенного представления в URI.
Если это возможно, URI должны только использоваться для адресации ресурсов, а не для туннелирования HTTP-методов / глаголов. В конце концов, конкретные бизнес-действия (редактирование, блокировка и т. Д.) Могут быть встроены в URI, если только создание (POST) или обновление (PUT) не служат цели:
POST http://shonzilla.com/orders/08/165;edit
В случае запроса определенного представления в URI вам нужно будет нарушить ваш дизайн URI, в конечном итоге сделав его более уродливым, смешав два разных понятия REST в одном месте (т. Е. URI) и усложнив обработку запросов на сервере в целом. -боковая сторона. Что предлагает Милан, и многие делают то же самое, в т.ч. Flickr, это точно.
Вместо этого более подход RESTful будет с использованием отдельного места для кодирования предпочтительного представления с использованием Accept
HTTP-заголовка, который используется для согласования содержимого, когда клиент сообщает серверу, какие типы содержимого он может обработать / process и сервер пытается выполнить запрос клиента. Этот подход является частью HTTP 1.1 стандарта , программного обеспечения, совместимого и поддерживаемого веб-браузерами.
Сравните это:
GET /orders/08/165.xml HTTP/1.1
or
GET /orders/08/165&format=xml HTTP/1.1
на это:
GET /orders/08/165 HTTP/1.1
<b>Accept: application/xml</b>
Из веб-браузера вы можете запросить любой тип содержимого, используя setRequestHeader
метод объекта XMLHttpRequest
. Например:
function getOrder(year, yearlyOrderId, contentType) {
var client = new XMLHttpRequest();
client.open("GET", "/order/" + year + "/" + yearlyOrderId);
client.setRequestHeader("Accept", contentType);
client.send(orderDetails);
}
Подводя итог: адрес, т. Е. URI ресурса, должен быть независимым от его представления, а метод XMLHttpRequest.setRequestHeader
позволяет запрашивать любое представление, используя HTTP-заголовок Accept
.
Ура!
Shonzilla