REST API - Как сделать запрос на обнаружение ссылок? - PullRequest
Новая
       11

REST API - Как сделать запрос на обнаружение ссылок?

0 голосов
/ 09 ноября 2018

Предположим, у меня есть RESTful HATEOAS API с конечной точкой /posts, в которой перечислены сообщения с ярлыком запроса /posts/new.Как запросить API, чтобы обнаружить /posts/new?

Мои идеи:

1) Запрос /posts и получение ссылок из атрибута _links (иперечисленные сущности требуют дополнительных затрат): 

GET /posts

{
  "docs": [
    ...
  ]
  "_links": {
    "new": { "rel": "posts", "href": "/posts/new" }
  }
}

2) Укажите это в корне API вместе со списком ресурсов: 

GET /

{
  "resources": {
    "posts": {
      "_links": {
        "self": { "rel": "posts", "href": "/posts" }
        "new": { "rel": "posts", "href": "/posts/new" }
      }
    }
  }
}

3) Я не должен использовать запрос /posts/new, а вместо этого использовать /posts и параметры запроса.Однако, если я изменю свою серверную логику, мне придется изменить и клиентскую логику, и это будет соединение клиент-клиент.Например:

  • Новые сообщения будут запрашиваться клиентом с помощью какого-либо параметра timestamp > (today - 30)
  • Я ввожу свойство draft и изменяю свое представление о том, что новыми являются только сообщения с timestamp > (today - 30) && draft = false
  • Мне нужно сменить клиента, чтобы добавить ограничение черновиков

Примечание: сообщения - это всего лишь пример, который я спрашиваю в общем.

Ответы [ 2 ]

0 голосов
/ 09 ноября 2018

В архитектуре REST URI должны быть обнаружены через сопровождающее их имя связи. При интерпретации приведенных выше примеров как HAL URI /post/new имеет имя отношения ссылки new. Имена отношений ссылок обеспечивают семантику URI, что позволяет клиентам определять, когда вызывать эти URI. HAL - это лишь один из нескольких типов носителей на основе JSON, которые поддерживают HATEOAS. Доступно дополнительных типов носителей , которые предоставляют аналогичную работу с немного отличающимся синтаксисом и возможностями.

После получения такого документа клиент будет анализировать сообщение и создавать некоторый контекст для сообщения, содержащего фактический контент, включая дополнительные метаданные, такие как ссылки и дополнительные встроенные данные. Если он хочет получить список самых последних публикаций, ему, в основном, нужно найти ключ (имя отношения ссылки), который выражает намерение (new в вашем случае) из вышеупомянутого контекста, чтобы извлечь назначенный значение (URI). Как клиент поддерживает этот контекст - это некоторые детали реализации. Он может создать древовидную карту для более удобного поиска ключей и их значений (URI) или использовать совершенно другой подход.

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

Указывает на ресурс, содержащий самые последние элементы в коллекции ресурсов.

Поэтому я бы предложил изменить имя отношения ссылки с new на current.

0 голосов
/ 09 ноября 2018

Итак, весь смысл RESTFUL в том, чтобы упростить обнаружение ссылок, приведя их в соответствие с HTTP-методом, используемым клиентом. Это означает, что все ваши ссылки будут просто называться /post, единственное, что изменится, это метод htpp и параметры, которые они принимают, которые ваш сервер будет использовать для определения фактической операции, которую хочет клиент.

Это пример из проекта C # (обратите внимание, что ссылки все одинаковые, единственными изменениями являются HTTP_METHOD и / или переданный параметр):

enter image description here

Список распространенных методов http: POST, GET, PUT, DELETE

...