Тип гиперссылки HAL + JSON не тип носителя для REST?

Можно использовать тип гиперссылки HAL + JSON таким образом, чтобы создать службу RESTful?Тип гиперссылки HAL + JSON не тип носителя для REST?

Из того, что я прочитал, клиенту RESTful API не нужно обрабатывать разные ресурсы в особых случаях. Вместо этого тип носителя следует использовать для описания того, какие ресурсы должны выглядеть.

HAL spec дает этот пример:

GET /orders 

{ 
    ... 
    "shippedToday": 20, 
    ... 
}

`` `

Как клиент этого образца HAL + JSON-обслуживающую API, я, кажется, нужно знать, что "порядок" имеет атрибут shippedToday. Это, похоже, противоречит ограничению, которое клиенту не нужно понимать синтаксис представления.

Это не критика HAL. Вопрос заключается в том, чтобы помочь моему (и другим) пониманию дизайна RESTful API.

источник

2016-07-28 edev

Может ли тип гиперссылки HAL + JSON использоваться таким образом, чтобы создать службу RESTful?

Да, определенно.

API должен иметь URL-адрес рекламного щита, который в вашем случае может быть /.

Это точка входа, из которой люди и даже машины могут начать поиск вашего API.

По представлению ресурсов в HAL specification содержит дополнительное свойство под названием "_links", которая описана здесь:

Это объект, свойство которого имена ссылка типы отношений (как , определяемой RFC5988) и значения либо объект Link или массив объектов ссылки.

Таким образом, эти ссылки представляют собой гипермедиа часть вашего API. Отношения могут быть связаны между собой, или вы можете использовать свои собственные отношения расширения.

Отношения не должны быть двусмысленными. Их имена должны быть уникальными. Вот почему рекомендуется использовать URI из вашего собственного домена в качестве имен для ваших собственных отношений. Эти URI идентифицируют ресурс, который представляет отношение, и содержит документацию по API, документацию, связанную с человеком или машиной, о вашей связи.

В вашем случае это будет отношение, которое описывает переход состояния к ресурсу /orders. Это должно также включать описание и объяснение ответа и, следовательно, документ, например, ресурс /orders представляет список заказов и имеет свойство «shippedToday» со значением номера типа.

Ниже приведен пример ответа на GET/HTTP/1.1 запросу:

HTTP/1.1 200 OK 
Content-Type: application/hal+json 

{ 
    "_links": { 
     "self": { "href": "/" }, 
     "http://yourdomain.com/docs/rels/orders": { "href": "/orders" }, 
    } 
}

Под http://yourdomain.com/docs/rels/orders должно быть API документы.

источник

2017-01-18 10:11:18 leifbattermann

Я читал это несколько раз сейчас, и это еще не значит, что я понимаю, что предоставляет HAL _links. Вы говорите, что я должен понимать из свойств _links, что я должен прочитать документацию, представленную в разделе «/ docs/rels/orders», чтобы узнать, как URL-адрес «/ orders» представляет собой набор конечных точек HAL, предлагающий функциональность CRUD в Orders? Мне просто кажется интуитивно понятным, что я должен использовать метку свойства как URL. – Adam

@Adam Да, это действительно немного противоречит интуиции. И ваше понимание этого правильно, насколько я могу судить. Чтобы сделать типы связей ссылок более читабельными, вы можете использовать CURIE (см. Http://stateless.co/hal_specification.html). – leifbattermann

Тип гиперссылки HAL + JSON не тип носителя для REST?

ответ

Смежные вопросы