Если API RESTful не требует, чтобы клиент знал иерархию ресурсов?

Question

Входная точка нашего API имеет rel с именем «x: reports» (где x - префикс, определенный в представлении HAL, посредством кюри - но это не важно сейчас).

Существует несколько видов отчетов. Вслед за «x: report» представлен набор этих разрешений, каждый из которых имеет свой собственный реестр - один rel называется «x: proofofplay». Существует набор значений поиска, связанных с этим типом отчета (и только этот тип отчета). Представление, возвращаемое следующим «x: proofofplay», относится к этому набору значений «x: произведение искусства».

Это приводит к следующей иерархии

reports 
    proofofplay 
    artwork 

В то время как «х: работа» ресурс довольно мал, это займет некоторое время, чтобы забрать его (10 сек). Таким образом, клиент решил асинхронно загрузить его при запуске приложения.

Чтобы получить ссылку «x: artwork», клиент должен следовать ссылкам. Я не уверен, что это проблема. Это кажется потенциально unRESTful, поскольку клиент зависит от внеполосного знания пути к этому ресурсу. Если когда-либо путь к художественным работам изменяется (крайне маловероятно), клиент сломается (хотя сами hrefs могут безнаказанно меняться).

Чтобы понять, почему я заинтересован, функция запуска выглядит следующим образом:

launch: function() { 
    var me = this; 
    Rest.getLinksFromEntryPoint(function(links) { 
     Rest.getLinksFromHref(links["x:reports"].href, function(reportLinks){ 
      Rest.getLinksFromHref(reportLinks["x:proofofplay"].href, function(popLinks){ 
       me.loadArtworks(popLinks["x:artwork"].href); 
      }); 
     }); 
    }); 
} 

Это трудно кодирование пути одновременно заставляет меня думать, что «это нормально - он основан на опубликованной модели ресурсов» и «Готов поспорить, Рой Филдинг будет злиться на меня».

Является ли это прекрасным, или есть лучший способ для клиента безопасно перемещаться по такой иерархии?

Answer 1

Ответ на вопрос HAL заключается в том, чтобы внедрить ресурсы.

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

Ваш клиент HAL должен идеально относиться к вещам в _links и вещам в _embedded как к тому же типу вещей, за исключением того, что во втором случае вы также заполняете HTTP-кеш для ресурсов.

Наши JS-клиент делает что-то вроде этого:

var client = new Client(bookMarkUrl); 
var resource = await client 
    .follow('x:reports') 
    .follow('x:proofofplay') 
    .follow('x:artwork') 
    .get(); 

Если какой-либо из этих промежуточных звеньев указаны в _links, мы будем следовать по ссылкам и делать GET запросы по требованию, но если таковые появились в _embedded, запрос пропущен и используется локальный кеш. Это имеет то преимущество, что в будущем мы можем добавить новые вещи от _links до _embedded и ускорить клиентов, которые не должны знать об этом изменении. Все без проблем.

В будущем мы намерены перейти от HAL _embedded, чтобы вместо этого использовать HTTP2 Push.