Хороший/плохой дизайн для объединения составного ключа с подчеркиванием в url?

Я ищу лучшие практики в дизайне API RESTful для следующего использования:

Table1     Table2
Id1        Id1
Id2        Id2
Id3        Id3
Name       Name
           Table1Id1(FK to Table1)
           Table1Id1(FK to Table1)
           Table1Id1(FK to Table1)

Предположим, что у я есть конечные точки, как показано ниже для таблицы 1:

/root/table1 (to get list of records)
/root/table2 (to get single record by primary key)

Теперь вот мой вопрос: какой будет лучший способ снизу до двух, чтобы представить составной ключ во втором URL:

/root/e1/Id1/Id2/Id3

or 

/root/e1?Id1=1&Id2=2&Id3=3

Предположим, что у я есть конечные точки, как показано ниже для таблицы 2:

/root/table1/Table1Id1_Table1Id2_Table1Id1/table2 (to get list of records for table2 by table1).

Теперь вот мой вопрос, который выше url действителен и уместен в случае составного ключа?

Приветствуются любые советы по хорошему шаблону для этого случая использования.

Ответ 1

Приветствуются любые советы по хорошему шаблону для этого случая использования.

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

Я ищу лучшие практики в дизайне API RESTful для следующего использования

ОТДЫХ действительно не волнует. Что касается REST, URI непрозрачен; любая информация, закодированная в нее, выполняется по усмотрению сервера и для собственного использования.

Соответствующими проблемами являются RFC 3986 и ваши локальные соглашения по дизайну.

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

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

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

Еще одна возможность для рассмотрения - параметры матрицы; вы можете объединить внешние ключи в один сегмент пути, тем самым избегая любого предложения иерархии между ними.

Ответ 2

Согласен с VoiceOfUnreason

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

Не делайте этого

Для вашего конкретного использования

Как общепринятая практика, REST Urls следует следовать предсказуемой и иерархической схеме для идентификации ресурсов. Это обеспечивает большую прозрачность между клиентом и сервером. Так что предположим, что у вас есть отношения родитель-ребенок в вашем сущности, лучше лучше спроектировать как

/{appname}/{version}/parent/{parentId}/child/{childId}

вместо того, чтобы иметь

/{appname}/{version}/child/{childId}

В вашем случае неиерархическая часть URL-адреса Id1/Id2/Id3

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

/root/e1?Id1=1&Id2=2&Id3=3

Это дает представление: "Получите мне e1 с идентификатором" 1 " и Идентификатором" 2 " и Идентификатором" 3 ", который является правильным в вашем контексте

/root/e1/Id1/Id2/Id3

Это нестандартно, поэтому его следует избегать

чтобы получить список записей для таблицы2 по таблице1

У вас должно быть

/root/table1/table2?Table1Id1&Table1Id2&Table1Id1

Ответ 3

Лучшее руководство по дизайну REST API, которое я видел на сегодняшний день, - это Google: https://cloud.google.com/apis/design/

По теме вашего вопроса он содержит эти 3 раздела:

Resource Oriented Design: обсуждает общий способ думать о ваших конечных точках.
Имена ресурсов: Описывает хорошие подходы к названию ваших ресурсов.
Стандартные методы: Описывает, когда использовать GET или POST и другие методы HTTP.

Это действительно хорошее чтение, которое я очень рекомендую.

Отвечая на ваш вопрос на основе руководства Google, я бы сказал: используйте /root/e1/Id1/Id2/Id3, а не другую версию, которая должна использоваться для создания новых записей.

Но, вероятно, вам не следует подвергать свою схему БД, как рекомендуют другие ответы. Поэтому я упомянул раздел "Ресурсно-ориентированный дизайн" выше. Вероятно, вам нужна какая-то абстракция поверх ваших таблиц. Если ваша операция не является явной операцией над самой схемой БД.