现状

Question

现状

我正在使用PHP开发在线订单管理系统应用程序，我需要通过URL方案设计REST资源映射。

我有典型的资源：

客户（有订单）
订单（有门票）
票证（有消息）
的消息

我在考虑这样的事情：

客户资料
```
example.com/customers/{customer-ID}
```

{customer-ID}的订单：

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

{order-ID}的门票：

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

{ticket-ID}的消息

example.com/customers/{customer-ID}/orders/{order-ID}/tickets/{ticket-ID}/messages

调查结果

有一天谷歌搜索，我发现了这些qutoes：

用户名后面的命名空间功能，如
```
example.com/{username}/followers
```
是针对每个用户的公开功能的绝佳解决方案。
帐户设置等私人内容不应该在用户名后面进行命名空间，而应该只在/account或/settings之后显示。
最好尽可能保持基本资源网址的精简。过滤，排序要求，高级搜索和分页都可以实现为查询参数
查询字符串应被视为页面的可选添加;即使删除了URL，该URL也可以生成有效且有用的页面。
在良好的黑客网址中，人员可以调整或删除部分路径，并从您的网站获得预期结果。它们可以让您的访问者更好地定位您的页面，并使他们能够轻松提升级别。
通过在您的路径中尽早嵌入唯一ID ，您可以在需要时获得详细的长描述网址，但仍然可以享受较短网址的可靠性和ID查找的速度。
向网址添加多个关键字可能有助于搜索引擎优化，但会让您的用户感到困惑。此外，您将很快冒被标记为关键字垃圾邮件发送者的风险。

问题

我做错了吗？
我应该避免命名空间客户，订单，门票和消息？
它是否有任何真正重大的安全问题？

提前致谢！

Answer 1

如果您描述的所有关系都是一对多（不是多对多），那么通过使用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。如上所示：

查看给定机票的所有订单：

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

查看客户的所有门票：

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

Answer 2

我做错了吗？

这取决于。您似乎走在正确的轨道上，但您最好先决定您的服务应该提供哪些功能。否则，最终可能会生成无限数量的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等返回，这也是一个很好的做法，也可以在URL中指定它。因此，请确定您的默认表示格式并将其公开为example.com/customers，然后在支持其他人的情况下将格式信息添加到网址的末尾

example.com/customers.xml

或

example.com/customers.html

等

希望它有所帮助！

我认为在网址中包含ID可能不是一个好习惯

嗯，有两种主要的方法，都有它和利弊。第一个是使用名称或短资源描述而不是ID。例如，您可以使用其名称example.com/customers/amazon代替客户端ID，其中amazon是您的客户名称。这种方法的另一个很好的例子是新闻网站，如果你浏览cnn.com，你会发现每篇文章的网址都包含文章标题http://edition.cnn.com/2016/06/10/middleeast/israel-tel-aviv-shooting/index.html - “特拉维夫嫌疑人发现隐藏在休班警察家中”

从SEO的角度来看这很棒，网址变得更具描述性和人性化。但是，如果您必须更改您的客户名称，则应更改网址，并且存在破坏客户的巨大风险。此外，在实施该方法时需要记住很多事项：

您应该正确验证客户名称，以便将其添加到网址
您应该拒绝更改客户名称或通过返回301（“永久移动”）并在Location标头中指定新网址以便客户端知道新网址来正确处理客户名称
等

ID方法的主要优点是网址始终是静态的，您不必担心上面的实现内容。

这两种方法从REST角度来看都是有效的，因此由您来决定

如何在Web应用程序URL结构中组织资源

现状

调查结果

问题

2 个答案: