Какой из этих URL-адресов является лучшим в соответствии со стандартами REST? - PullRequest
Новая
       14

Какой из этих URL-адресов является лучшим в соответствии со стандартами REST?

0 голосов
/ 05 июня 2019

Я пытаюсь найти лучший / правильный способ создания URL-адресов моих остальных API, но я путаюсь между company ресурсом.

Это ресурс company, расположенный по адресу http://localhost:8085/api/v1/company/1. Это вернет мне некоторые основные данные из таблицы company.

Хорошо до сих пор. Но сейчас компания может быть двух типов: 1. Механическая 2. Другая. У каждого есть своя соответствующая таблица в БД с отношением 1:1 к таблице company Чтобы получить более подробную информацию о компании, мне нужно предоставить две другие таблицы из какой-то конечной точки API.

Итак, я запутался между тремя URL-адресами здесь:

  1. http://localhost:8085/api/v1/company/1?type=mechanical
  2. http://localhost:8085/api/v1/company/1/mechanical
  3. http://localhost:8085/api/v1/company/mechanical/1

Я отклоняю опцию 1 по одной причине, которую я нашел в SO, т.е. пути с параметрами не могут быть кэшированы. Стандарт покоя: параметры пути или параметры запроса

Я в основном путаюсь между 2 и 3? Какой будет правильный путь?

Один вопрос, который вы можете задать, почему я не предоставляю полную информацию о компании с http://localhost:8085/api/v1/company/1? Это потому, что я хочу воспользоваться Lazy Loading. Сбор информации о компании может занять больше времени, поэтому я разделил содержимое.

1 Ответ

0 голосов
/ 06 июня 2019

Я пытаюсь найти лучший / правильный способ для создания URL-адресов моих остальных API, но я запутался в ресурсах компании.

REST не заботится о том, какое правописание вы используете для своих URL, если они соответствуют RFC 3986 . URI являются идентификаторами , не требуется, чтобы написание идентификатора было каким-либо образом связано с его семантическим значением.

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

Чтобы получить более подробную информацию о компании, мне нужно предоставить две другие таблицы из какой-то конечной точки API.

Отчасти REST заключается в том, что ваша модель ресурсов может не быть тесно связана с вашей моделью данных. «В интернете никто не знает, что ты собака». Вы, конечно, можете создать ресурсы для каждой части вашей реляционной схемы.

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

Я отклоняю опцию 1 по одной причине, которую я нашел в SO, т.е. пути с параметрами не могут быть кэшированы.

Я почти уверен, что это очень плохой ответ и, следовательно, плохая поддержка данного дизайна. Но опять же, REST не заботится о правописании. 

http://localhost:8085/api/v1/company/1?type=mechanical
http://localhost:8085/api/v1/company/1/mechanical
http://localhost:8085/api/v1/company/mechanical/1

Все это отлично .

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

http://localhost:8085/api/v1/company
http://localhost:8085/api/v1/company/1
http://localhost:8085/api/v1/company/mechanical

Учитывая то, что вы описали здесь, вариант # 2 выглядит более полезным, чем его кузены.

Если относительное разрешение не является важным вариантом использования, то вы можете рассмотреть возможность использования нового ствола 

http://localhost:8085/api/v1/mechanical-company/1

Во первых это должны быть / компании

Только если это местное соглашение о правописании. 

/company/1
/companies/1
/c5y/1
/c6s/1
/compagnie/1
/c5be6eed-3df2-4987-aceb-1b2f8909cb85/1
/purpleMonkeyDishwasher/1

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

...