Обход и практичность Hypermedia API Link

Question

Я пытался создать API на основе гипермедиа. Вещи, кажется, работают хорошо. Скажи, когда я принесу /books/isbn/12313441213 Я получаю что-то вроде этого:

<book>
  <id>123</id>
  <name>Hypermedia APIs</name>
  <description>Basic api design techniques</description>
  <tags>
    <tag>rest</tag>
    <tag>api</tag>
    <tag>service</tag>
  </tags>
  <authors>
    <link rel="author" uri="/authors/id/22" />
    <link rel="author" uri="/authors/id/18" />
  </authors>
</book>

Теперь я могу проследить авторов с этого ресурса. Когда я получу /books/by/author/id/18 Я получаю что-то вроде этого:

<books>
  <book id="123">
    <name>Hypermedia APIs</name>
    <link rel="self" uri="/books/id/123" />
  </book>
  <book id="191">
    <name>Chef Recipes for Rails Developers</name>
    <link rel="self" uri="/books/id/191" />
  </book>
  <book id="220">
    <name>Rails 4 Cookbook</name>
    <link rel="self" uri="/books/id/220" />
  </book>
  <book id="292">
    <name>Ruby 102</name>
    <link rel="self" uri="/books/id/292" />
  </book>
  <book id="432">
    <name>Semantic Architecture</name>
    <link rel="self" uri="/books/id/432" />
  </book>
  <book id="501">
    <name>Service Oriented Design</name>
    <link rel="self" uri="/books/id/501" />
  </book>
</books>

Который также, кажется, работает хорошо для меня. Является ли этот способ создания шаблонов URI хорошим, мой вопрос заключается в том, насколько практичным является переход по таким ссылкам?

Учитывая, что вы хотите получить исчерпывающий ресурс (включая сведения об авторе), вам необходимо сделать как минимум 3 вызова на сервер. Опять же для сбора, вы должны сделать тонны звонков на сервер. Да, может быть, я мог бы использовать расширение ресурсов здесь, но тогда зачем вообще использовать гиперссылки, поскольку все мои клиенты будут вовремя использовать расширенные ресурсы.

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

Либо я не получаю что-то в дизайне гипермедиа API, либо гипермедиа API звучит здорово, но кажется, что это просто теоретическая идея, а не практическая.

Есть мысли по этому поводу?

Answer 1

Это великий вопрос всех времен. На самом деле, еще один большой вопрос: кто знает, как обращаться к конкретному ресурсу R?

Например, чтобы добраться до ресурса "book-detail", клиент должен сделать вызов для входа в ваш API, например, "/", затем с помощью rel "book-Categories" получить uri для book-category, затем сделать вызов OPTIONS для Посмотрите, возможна ли операция GET на этом ресурсе, затем получите категории книг, затем получите ссылку на ресурс "книги в категории" и т. д., который в конечном итоге переходит к ресурсу "Детали книги". Этот путь прохождения к ресурсу R должен быть частью знаний клиента. Но не кодируйте URL-адреса жестко, просто читайте их во время выполнения. Это рассматривает сценарий "человек-машина". Неэффективность все еще там. В случае межмашинного сценария автомат, начинающийся с "/", может пройти через ваш API и выполнить определенную обработку ваших ресурсов. Если автомат должен достичь всех ресурсов в дереве (или может быть конечным автоматом), тогда не будет неэффективности. Но если автомату нужно вызвать ресурс вниз по дереву, и он знает только точку входа API, он столкнется с проблемой выполнения нескольких вызовов для достижения этой точки.

Многие скажут вам ввести кеширование с использованием etags и / или memcached, но кеширование должно повысить производительность, вы не можете зависеть от кэшей на 100%, потому что кэши устаревают, поэтому в этих случаях код для обхода ресурсов R1-Rn должен быть в вашем клиент.

проверьте мой вопрос на: https://stackru.com/questions/15214526/why-hypermedia-api

Но чтобы ответить на ваш вопрос о практичности: если у вас есть бизнес-процесс, в котором клиент должен перейти к ресурсу R1, затем R2, то... Rn, и вы хотите применить этот поток, гипермедиа практична. Я предполагаю, что нет прямых вызовов Resource Rx без прохождения через R1 -> R2 ->... Rx-1.

Answer 2

Было бы более традиционно использовать параметры:

GET / books? Author=18

Я ожидаю, что ответ будет выглядеть примерно так:

Гипермедиа API

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

GET /books/18? Развернуть = автор (имя, день рождения)

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

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

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