REST Выборка родительской сущности дочерней сущностью - PullRequest
Новая
       61

REST Выборка родительской сущности дочерней сущностью

0 голосов
/ 27 февраля 2019

Основываясь на этом вопросе из приведенного здесь примера Каковы наилучшие практики для вложенных ресурсов REST?

Как будет выглядеть конечная точка, если вы хотите получить компанию, в которой работает сотрудник?Возможные варианты:

  1. GET /companies?employeeId=x предположительно вернет список компаний, где employeeId = x
  2. GET /companies/by-employee/{employeeId} вернет одну компанию.Эта конечная точка черпает вдохновение из / dev / disks / символических ссылок в системах Linux.По сути, это псевдоним компании по всем их дочерним объектам
  3. GET /employees/{employeeId}/company возвращает одну компанию и инвертирует отношения между сотрудниками и компаниями

1 Ответ

0 голосов
/ 27 февраля 2019

Как бы выглядела конечная точка, если бы вы хотели выбрать компанию, в которой работает сотрудник?

REST не имеет значения, какое правописание вы используете для идентификаторов ресурсов.

Подумайте о том, как работает браузер, когда он загружает HTML-страницу.Предположим, есть тег img;тег дает браузеру тот семантический контекст, который ему нужен, чтобы он мог отправить запрос на изображение (и, в частности, отправить запрос с его предпочтительными типами image ).Браузеру не нужно анализировать URL-адрес, искать расширения файлов или что-то в этом роде, чтобы выяснить, является ли ресурс изображением.

Попытка закодировать семантику в URI - неправильный путь;семантика содержится в ссылках .

Если вы разрабатываете REST API, вам нужно что-то аналогичное 

Link: </F4EEFDD3-44D9-41AD-8299-620ECD8765DB>; rel="https://schema.org/Organization"

Перевод: эта ссылка "указывает на«Ресурс, который является организацией текущего контекста.

Клиент и Сервер должны иметь контракт, который описывает, какие ссылки возможны и что они означают, точно так же, как спецификация HTML описывает семантику. a elements , img elements и т. д.

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

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

Link: </F4EEFDD3-44D9-41AD-8299-620ECD8765DB>; rel="https://schema.org/Organization"
Link: </companies?employeeId={employeeId}>; rel="https://schema.org/Organization"
Link: </companies/by-employee/{employeeId}>; rel="https://schema.org/Organization"
Link: </employees/{employeeId}/company>; rel="https://schema.org/Organization"

/companies?employeeId={employeeId} - удобный идентификатор, потому что выможет также использовать его с помощью правил обработки форм HTML .

/companies/by-employee/{employeeId} и /employees/{employeeId}/company может быть удобным, поскольку вы можете использовать относительное разрешение и точечные сегменты для ссылки надругие ресурсы в удобных местах в иерархии идентификаторов.

Рекомендуемый просмотр: Тилков ОТДЫХ: Я не думаю, что это означает то, что вы думаете, что означает .

...