rest - REST slug 本地化。我应该将翻译放入 slug 中吗？

Question

如果我的宁静 URL 看起来像这样：

http://example.com/en/city/波士顿

http://example.com/de/stadt/波士顿

或像这样：

http://example.com/en/city/波士顿

http://example.com/de/city/波士顿

Answer 1

REST API 经常提倡的规则是，每个资源都应该只有一个 URI，并且应该使用 HTTP 标头来协商如何访问或操作它。然而，关于如何确定什么构成独特资源以及什么仅仅是该资源的不同表示，仍有一些争论的余地

在您的示例中，可以说每个城市都是一种资源，但有关该城市的数据的翻译是一种表示。这表明 URL 应始终为http://example.com/city/boston，并使用 HTTPAccept-Language标头选择区域设置。

另一种解释是，您实际上是在呈现多个 API，每个 API 都完全本地化 -http://example.com/en/英语 API 的基本 URL 也是如此，而http://example.com/de/德语 API 的基本 URL 恰好提供对相同资源的类似访问。这意味着这两个 API 不需要保持同步，并且可以针对目标受众进行定制；具体来说，它会建议http://example.com/de/stadt/Boston在德语 API 中使用更好的 URL。

还要记住，资源本身的名称可能具有本地化等价物，而不仅仅是像“城市”这样的资源类型 - 所以如果城市确实是您的资源类型，则http://example.com/en/city/Vienna对应于http://example.com/de/stadt/Wien. 这完全是人类可读的，但可能很难构建到底层数据模型中。

如果您的意图只是以尽可能多的语言呈现相同的内容，那么从 URL 中完全删除区域设置并依靠内容协商 Accept-Language似乎是更“RESTful”的解决方案。如果您特别有一个单独的英语和德语市场，可能不需要相同的内容和功能，那么本地化 URL 似乎是有意义的。

Answer 2

没有像 RESTful URL 这样的东西。两组 URI 都是完全有效的。选择对您的服务器端框架更容易处理的那个。我的猜测是那将是第二个。