如果您描述的所有关系都是一对多（而不是多对多），那么我真的看不到您通过URL获得了什么，例如，当订单ID已知时，包含客户ID。它是冗余信息，并且不会在控制器中提供额外的有用信息。
事实上，它可能会导致比预期更复杂的情况，因为现在你必须处理可能是客户订单ID不匹配的情况。您现在必须检查所有这些条件，并在出现这些错误条件时返回错误的请求响应。为什么要增加这些开销？
也许只是：
客户概况：

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之外，您可能还需要以下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头中。
也请考虑添加版本信息到您的网址。当您必须支持多个版本的服务时，它会非常有用

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

或

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

等等的。
最后，如果您要支持资源的多种表示，例如，您可以将客户端列表返回为JSON，XML，HTML等。这是一个很好的做法，指定它在网址以及。因此，请确定默认的表示格式，并将其公开为example.com/customers，然后在url末尾添加格式信息（如果您支持其他格式）。

example.com/customers.xml

或

example.com/customers.html

等等的。
希望能帮上忙！
我认为在URL中包含ID可能不是一个好的做法
嗯，有两种主要的方法，都有利弊。第一个是使用名称或短资源描述而不是ID。例如，您可以使用其名称example.com/customers/amazon来代替客户端ID，其中amazon是您的客户端名称。该方法的另一个很好的例子是新闻网站，如果你浏览cnn.com，你会看到每篇文章的url都包含文章标题http://edition.cnn.com/2016/06/10/middleeast/israel-tel-aviv-shooting/index.html-“特拉维夫suspect discovered hiding in home of off-duty cop”
从SEO的Angular 来看，这是很棒的，URL变得更具描述性和人性化。但如果你必须更改客户名称，它应该更改URL，并且存在破坏客户端的巨大风险。此外，在实施该方法时，还有很多事情需要记住：

• 您应该正确地验证客户名称，以便可以将其添加到URL中
• 您应该禁止更改客户名称，或者通过返回301（“Moved permanently”）并在Location头中指定新的URL来正确处理它，以便客户端知道新的URL
• 等等的。

ID方法的主要优点是URL总是静态的，你不必为上面的实现内容而烦恼。
从REST的Angular 来看，这两种方法都是有效的，因此由您来决定