对于restfull服务，名词可以省略并丢弃吗？
而不是/service/customers/555/orders/111
可以/应该公开：/service/555/111？
第一个选项是强制性的还是有几个选项，这是值得商榷的？
答案 0 :(得分：3)
这完全取决于你，我认为拥有名词的好处在于它可以帮助您从URL中看到服务正在尝试实现的目标。
另外考虑到在客户下你可以有类似下面的内容，从URL可以区分客户的订单和报价
答案 1 :(得分：2)
在某种程度上，命名RESTful端点的“规则”应遵循与“清洁代码”相同的命名规则，例如教导。
含义：名字应该意味着什么。他们应该说出他们的意思，并说出他们所说的话。
来自那里：它可能取决于该服务的性质。如果您只能“服务”客户 - 那么您可以省略客户部分 - 因为这不会添加（很多）有意义的信息。但是，如果您以后想要为其他类型的客户提供服务怎么办？
换句话说：我们无法告诉您什么是适合您的应用程序 - 因为这取决于您的环境的要求/目标。
值得注意的是：不仅要考虑今天的要求。退一步考虑那些看起来最有可能的“未来增长路径”。然后确保您今天定义的API能够很好地处理最有可能发生的未来扩展。
答案 2 :(得分：2)
REST的核心方面之一是URL应被视为不透明的实体。客户端永远不会创建网址，只需使用服务器提供的网址。只有托管实体的服务器才需要了解URL结构。
因此，在设计服务时，请使用对您最有意义的URL方案。
关于您提到的选项：
/service/customers/555和/service/orders/1234567。无论如何，从服务返回的RESTful客户文档应该包含指向他或她的订单的链接，反之亦然（以及所有其他相关关系）。
答案 3 :(得分：1)
而不是/ service / customers / 555 / orders / 111
可以/应该公开：/ service / 555/111？
问题很广泛，但是当您使用REST路径来定义嵌套信息时，必须尽可能明确地显示嵌套信息。
如果在URL中提供长路径对您来说是个问题，则可以在请求正文中提供上下文信息。
我认为短路/service/555/111缺乏一致性。
假设/service/555/111对应于为客户555和订单111调用服务。
你知道的。但API的客户并不一定知道路径意义是什么。
此外，现在假设您希望为客户555调用相同的服务，但是对于2018年。现在怎么样？
像那样 ：
/service/555/2018会出错，因为您必须添加一个参数来传达最后一个路径值，service/555/years/2018会使您的API定义不一致。
清晰，简洁和一致性很重要。
答案 4 :(得分：1)
根据我的说法，名词的使用不是必需的，也不是任何标准，但是它的用法可以帮助你的终点更具体，更易于理解。
因此，如果任何术语使您的URL更易于阅读或易于理解，那么我通常更喜欢创建并保持简单的类型或URL。它还可以帮助您的服务消费者通过名称本身部分了解任何服务的功能。
答案 5 :(得分：0)
请按照https://restfulapi.net/resource-naming/了解最佳做法。
答案 6 :(得分：0)
对于restfull服务，名词可以省略并丢弃吗？
是。 REST并不关心您用于资源标识符的拼写。
网址缩短工作就好了。
拼写的选择取决于地方惯例，它们就像那个意义上的变量。
理想情况下，拼写独立于底层域和数据模型，因此您可以在不更改API的情况下更改模型。吉姆韦伯以这种方式表达了这个想法
网络不是您的域名，它是一个文档管理系统。所有HTTP谓词都适用于文档管理域。 URI不会映射到域对象 - 这违反了封装。工作（例如：向域模型发出命令）是管理资源的副作用。换句话说，资源是反腐败层的一部分。您应该希望集成域中的资源比业务域中的业务对象多得多。
资源调整您的网络域模型
也就是说，如果您希望客户在您的文档中发现URI（而不是通过从指定的超媒体响应中读取它们），那么使用遵循简单概念模型的URI拼写将是一个好主意。