REST slug本地化。我应该把翻译放入slug吗？

Question

我的其他网址应该是这样的：

http://example.com/en/city/Boston

http://example.com/de/stadt/Boston

或者像这样：

http://example.com/en/city/Boston

http://example.com/de/city/Boston

Answer 1

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

Answer 2

通常主张REST API的规则是每个资源应该只有一个URI，并且应该使用HTTP头来协商如何访问或操作它。然而，对于你究竟如何确定什么构成一个独特的资源，以及仅仅是该资源的不同表示，还有一些争论的空间

在您的示例中，可以说每个城市都是一个资源，但有关该城市的数据的翻译是一种表示。这表明网址应始终为http://example.com/city/boston，并使用HTTP Accept-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似乎是有道理的。