Ако всички връзки, които описвате, са едно към много (не много към много), тогава не виждам какво печелите, като имате URL адреси, които например съдържат идентификатор на клиент, когато идентификаторът на поръчката е известен. Това е излишна информация и няма да предостави допълнителна полезна информация във вашите контролери.

Всъщност това може да причини ПО-ВЕЧЕ сложност от желаното, тъй като сега трябва да се справяте със случаи, в които може да има несъответствие на идентификатора на клиент за поръчка. Сега трябва да проверите всички тези условия и да върнете лош отговор на заявка, ако възникнат тези лоши условия. Защо да добавяте тези режийни разходи?

Може би само:

Клиентски профил:

example.com/customers/{customer-ID}

Поръчки за {customer-ID}:

example.com/customers/{customer-ID}/orders

Билети за {order-ID}:

example.com/orders/{order-ID}/tickets

Съобщения за {ticket-ID}

example.com/tickets/{ticket-ID}/messages

Ако обаче сте имали връзка много към много, това може да се промени. Да кажем например, че клиент може да въведе един билет, който покрива множество поръчки (което означава, че билетите вече са по-свързани с клиента, отколкото със самата поръчка), тогава може да имате нужда от URL адреси като следния в допълнение към показаните по-горе:

Вижте всички поръчки за даден билет:

example.com/tickets/{ticket-ID}/orders

Вижте всички билети за клиент:

example.com/customer/{customer-ID}/tickets

Правя ли нещата погрешно?

Зависи. Изглежда, че сте на прав път, но е по-добре първо да решите каква функционалност трябва да предостави вашата услуга. В противен случай може да се окажете с безкраен брой url (ресурси) за внедряване. Например, ако трябва да изложите списък с поръчки за всички клиенти, ще искате да имате example.com/orders ресурс с параметри на низ на заявка, за да посочите критерии за търсене. В противен случай ще трябва първо да се направи запитване към всички клиенти и след това в цикъл да се изпращат заявки до example.com/customers/{customer-ID}/orders, за да се получат всички поръчки за всички клиенти. Така че първо помислете каква функционалност трябва да изложи вашата услуга и след това проектирайте ресурсите за нея.

Има ли наистина сериозни опасения за сигурността?

Няма нищо общо с дизайна на url (ресурси). Информацията за удостоверяване и упълномощаване обикновено влиза в http заглавките.

Също така, моля, помислете за добавяне на информация за версии към вашите URL адреси. Оказва се, че е супер полезно, когато трябва да поддържате няколко версии на вашите услуги

example.com/v1/customers/{customer-ID}/orders

or

v1.example.com/customers/{customer-ID}/orders

и т.н.

И накрая, ако ще поддържате множествено представяне за ресурс, например, можете да върнете списъка с клиенти като JSON, XML, HTML и т.н. добра практика е да го посочите и в URL адреса. Затова вземете своя формат за представяне по подразбиране и го изложете като example.com/customers и след това добавете информация за формата в края на URL адреса, ако поддържате други

example.com/customers.xml

or

example.com/customers.html

и т.н.

Дано помогне!

Мисля, че включването на идентификатори в URL може да не е добра практика

Е, има два основни подхода и двата имат своите минуси и плюсове. Първият използва имена или кратко описание на ресурса вместо ID. Например, вместо идентификатор на клиент можете да използвате неговото име, example.com/customers/amazon, където amazon е името на вашия клиент. Друг добър пример за подхода са новинарските сайтове, ако навигирате през cnn.com, ще видите всеки URL адрес на статия да съдържа заглавие на статия http://edition.cnn.com/2016/06/10/middleeast/israel-tel-aviv-shooting/index.html - „Заподозреният в Тел Авив е открит да се крие в дома на полицай извън службата“

Това е страхотно от гледна точка на SEO и URL адресите стават по-описателни и удобни за хората. Но ако трябва да промените името на клиента си, това трябва да промени URL адреса и има огромен риск от прекъсване на клиентите. Освен това има много неща, които трябва да имате предвид, докато прилагате подхода:

• Трябва правилно да потвърдите имената на клиентите, така че да могат да бъдат добавени към URL адрес
• Трябва или да забраните промяната на името на клиента, или да я обработите правилно, като върнете 301 („Преместено за постоянно“) и посочите новия URL адрес в заглавката на местоположението, така че клиентът да е наясно с новия URL адрес
• и т.н.

Основното предимство на подхода за идентификатори е, че URL адресите винаги са статични и не е нужно да се притеснявате за нещата по внедряването по-горе.

И двата подхода са валидни от гледна точка на REST, така че зависи от вас да решите