所以我在这里有一个困境。尝试构建RESTful API。这意味着我希望定义资源，并要求消费者通过id引用这些资源。
例如，典型的{resourceName} / {id}？{querystring}
但是，对于电子商务网站而言，网络用户界面的工作方式当然是您自然拥有SEO友好网址。
因此，在应用程序特定的URL方面存在不匹配，其中我们有基于应用程序上下文的URL，上下文是使用SEO友好URL的电子商务站点。他们100％的时间都没有/ id这样的东西。实际上，我们的网站在网页用户界面中没有任何ID。
因此，当用户从一个页面转到另一个页面时，我们可能会有www.ourdomain.com/cars/local/usa/ca/sunnyvale-cars这样的网址。有时我们正在讨论在UI开发者发送请求之后，从更加seo友好的URL中剥离' - '或其他角色，比如说就像国家资源一样。如果我想要关于那个城市的信息，那么UI团队可能会向我发送'/ cities？name = sunnyvale-cars'，我们的API需要剥离城市，我会将城市名称从'sunnyvale-cars'中剥离出来name是为了在后端进行查询，对我来说这听起来不像我们的API应该做的事情。它还将我们的REST API与Web和Web约定相结合......我们的REST API应该不知道任何类型的交付机制，以便我们的API可以重用于我们业务域中的其他应用程序或其他API。
可能有时候UI工程团队，实际上很多时候他们只会有这样的URL。没有用户操作或让我们说下拉列表，他们可以只获取一个ID。因此，他们不能总是通过每次向我发送RESTful URI请求来请求下一页的内容，因为它们可能始终没有ID。换句话说，有时候他们不得不要求这样的东西：/ states？name =“ca”来获取与该状态相关的东西，就像一个假设的例子。
那么，如果您的UI团队告诉您他们不会拥有所有内容的ID，那么您在世界上甚至可以构建一个REST API？
答案 0 :(得分：1)
从REST纯粹主义者的观点来看，只要两者都使用标识资源，URI本身就不会比另一个更加RESTful。至少，我在original thesis中找不到任何相关内容。
但是，如果您发现某些结构更适合您的API，则可以专门为UI团队的需求创建第二个端点。该端点将作为代理，并以简单的方式简单地将SEO友好的结构映射到您的API。
或者，来自外部的应用程序只需要进行重写或任何特定于应用程序的映射到REST API＆＃34;东西＆＃34;因为它无论如何都是应用程序特定的应用程序，因此保持API不了解应用程序特定的细节，域逻辑，甚至是API不应该关心或甚至不知道的Web约定。