REST HATEOAS: Как определить и установить медиа-тип при просмотре ссылок?

Я просматривал то, что было описано как пример хороший REST API. GET был отправлен на базовом URI и с медиа-типом, который каким-то образом уже был известен клиенту (что нормально, согласно принципам REST).

 To server:

 GET /
 Host: xrgy.cloud.sun.com
 Authorization: Basic xxxxxxxxxxxxxxxxxxx
 Accept: application/vnd.com.sun.cloud.Cloud+json
 X-Compute-Client-Specification-Version: 0.1

 From Server:

 HTTP/1.1 200 OK
 Content-Type: application/vnd.com.sun.cloud.Cloud+json
 Content-Length: nnn

 {
   "implementation_version": "597",
   "vdcs": [
     {
       "name": "XRGY Virtual Data Center",
       "uri": "/vdc"
     }
     {
       "name": "R&D sandbox"
       "uri": "/sandbox"
     }
   ],
   "uri": "http://xrgy.cloud.sun.com/",
   "specification_version": [
     "0.5"
   ]
 }

Но я застрял в том, как клиент устанавливает тип носителя для последующего запроса. Я понимаю, что клиент получил URI для следующего запроса из предыдущего ответа. Но откуда у него медиа-тип? Если это предварительная информация для клиента, то как клиенты обычно поддерживают такие сопоставления URI: media-type? Кажется, я определенно упускаю некоторые базовые знания здесь. Вот следующий запрос, отправленный с медиа-типом: application / vnd.com.sun.cloud.Vdc + json!

To server:

 GET /vdc
 Host: xrgy.cloud.sun.com
 Authorization: Basic xxxxxxxxxxxxxxxxxxx
 Accept: application/vnd.com.sun.cloud.Vdc+json
 X-Compute-Client-Specification-Version: 0.1

From server:

 HTTP/1.1 200 OK
 Content-Type: application/vnd.com.sun.cloud.Vdc+json
 Content-Length: nnn

 { 
   "name" : "XRGY Virtual Data Center",
   "uri" : "http://xrgy.cloud.sun.com/vdc",
   "vm_templates" : "http://cloud.sun.com/resources/template-cat.json",
   "addresses" : [
     {
       "name": "144.34.100.199",
       "uri": "/addresses/144.34.100.199",
       "ip_address": "144.34.100.199"
     }
   ],
   "cluster" : {
     "name" : "ROOT",
     "uri" : "/vdc/",
     "tags" : [ ],
     "volumes" : [ ],
     "clusters" :  [
     ]
     "tags" : [ ],
     "controllers" : [
       "start" : "/vdc/ops/start",
       "stop" : "/vdc/ops/stop",
     ]
     "vnets" : [
       {
         "name": "vnet1",
         "uri": "/vnets/10.31.145.0",
         "netmask": "255.255.255.0",
         "network": "10.31.145.0"
       }
     ],
     "vms": [
       {
        * SNIPPED *
       }
     ]
   }
 }

Я видел другие примеры, где медиа-тип также является частью ссылок в ответе, например, этот следующий ответ, и я могу это понять.

201 Created
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8

<transfer xmlns="urn:org:bank:accounts">
    <link rel="self"
          href="http://bank.org/transfer/XTA8763"/>
    <link rel="http://bank.org/rel/transfer/from"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/AZA12093"/>
    <link rel="http://bank.org/rel/transfer/to"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/ADK31242"/>
    <link rel="http://bank.org/rel/transfer/status"
          type="application/vnd.bank.org.status+xml"
          href="http://bank.org/check/XTA8763"/>
    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

person 2020    schedule 03.04.2013    source источник
comment
нашел очень хороший ответ на часть этого qn в другом месте   -  person 2020    schedule 16.04.2013


Ответы (2)


Проще говоря, да, клиент должен иметь некоторые априорные знания о задействованных типах медиа. Поскольку клиент фактически устанавливает типы мультимедиа, которые он может потреблять. Поскольку клиент понимает только «некоторые» типы мультимедиа, если он отправляет запрос с типом мультимедиа, который приложение не поддерживает, то клиенту в значительной степени не повезло.

Поскольку в реальном мире мы стараемся не допускать, чтобы клиенты слепо обращались к службам, возвращающим полезные данные, которые они не понимают, у клиента будет некоторое предварительное знание задействованных полезных нагрузок, особенно очень конкретных типов (по сравнению с обычным / текстовым или приложение / xml).

Наконец, напомним, что тип носителя фактически сообщит вам СИНТАКСИС полезной нагрузки, но не то, как интерпретировать полезную нагрузку. Эту семантику ваш клиент также должен будет знать заранее, поэтому бремя первоначального понимания типа носителя на самом деле не является особенно препятствием для участия, это просто факт жизни.

person Will Hartung    schedule 03.04.2013

Клиенты несут ответственность за то, чтобы сообщить серверам, какой ответ они понимают / предпочитают. Это то, что указывает заголовок Accept. Серверы отвечают контентом, который пытается удовлетворить запрос клиента. Заголовок Content-Type указывает, что фактически возвращается. В идеале значение этого заголовка такое же, как и значение заголовка Accept.

См. Разделы 14.1 и 14.17 в RFC 2616.

В вашем примере автор клиента, вероятно, вводит знания в клиента, и это не действительно 100% клиент RESTful.

person David Peden    schedule 03.04.2013
comment
У меня нет сомнений в значении заголовка Accept в заголовке запроса и заголовка Content-type в ответе. Извините, если в моем вопросе использовалось «content-type» в местах, где использовались shd «Accept header». Исправили это в вопросе сейчас, и теперь я использую «медиа-тип» в целом. Мой вопрос более уместен, если учесть, что этот REST API - это упоминается как отвечающий стандарту GOLD. Итак, я предполагаю, что он должен способствовать развитию хорошего РЕСТОРАННОГО клиента !? - person 2020; 04.04.2013
comment
Круто, учитывая эту путаницу, я вставил ответ котельной плиты. Что касается согласованного золотого стандарта, я не знаю, что он есть. В этом списке из вашего связанного сообщения просто упоминаются наиболее часто используемые API, не обязательно самые RESTful. Для клиентов разумно знать об общем типе контента, который могут предложить серверы. В конце концов, всегда есть одна хорошо известная конечная точка, из которой исходят все последующие потоки. То, что в примере клиента, который вы опубликовали, переключает заголовки Accept в середине потока с нулевым указанием на это, предполагает жестко запрограммированные знания. - person David Peden; 04.04.2013
comment
И вы говорите, что такие знания делают клиента не таким уж задумчивым? Ответ Уилла предполагает, что такое знание неизбежно, если только сервер не ограничивается стандартными типами носителей. - person 2020; 04.04.2013
comment
Нет, я не говорил, что это не RESTful. Я согласен с ответом Уилла. Клиент должен понимать семантику ответа, чтобы согласованная структура была ценной. - person David Peden; 04.04.2013