我目前正在开发一个或多或少的RESTful webservice，这是我公司文章的一种内容api。我们目前有一个资源来获取特定文章的所有内容
http://api.com/content/articles/{id}
将返回给定文章ID的完整文章数据。
目前我们控制了很多文章的业务逻辑，因为我们只提供来自网络服务的本机应用程序。这意味着我们将文章正文中的标签，链接，图像等转换为本机应用程序可以理解的协议。与本文中的大量不同属性和数据相同，我们将其原始（Web）状态转换并修改为本机应用程序将理解的状态。
FX。 img标记会从普通<img src="http://source.com"/>转换为<img src="inline-image//{imageId}"/>标记，samt会转换为锚标记等。
现在我必须实现一个可以以新的表示形式返回文章数据的资源
我对如何最好地做到这一点感到困惑。
我可以在不同的网址上实施一个全新的资源：content/articles/web/{id}并将旧资源移至content/article/app/{id}
我还可以在我的资源文档中指定客户端应始终为Web服务指定特定的request header可能Accept标头，以确定要返回的文章的哪个表示形式
我也可以使用原始网址，并使用url parameter或.../{id}/?version=app
.../{id}/?version=web
你们认为什么是最好的选择？我的个人偏好倾向于选项1，仅仅因为我认为它更容易理解为Web服务的客户。
问候，马丁。
编辑：
我选择使用选项1.感谢您提供帮助并给予利弊。 ：）
答案 0 :(得分：2)
使用Content Negotiation的HTTP概念。使用Accept标题和供应商类型。
以原生表示形式获取文章：
GET /api.com/content/articles/1234
Accept: application/vnd.com.exmaple.article.native+json
获取原始表示中的文章：
GET /api.com/content/articles/1234
Accept: application/vnd.com.exmaple.article.orig+json
答案 1 :(得分：2)
我会选择＃1。如果您需要保留现有网址，则可以添加新网址content/articles/{id}/native或content/native-articles/{id}/。两者都足够REST。
使用路径使内容比header或param选项更容易缓存。使用Content-Type会使服务过于复杂，尤其是当两者都返回JSON时。
答案 2 :(得分：1)
两者都是非常好的解决方案。我喜欢选项1看起来更好的方式，但这只是美学。这并不重要。如果您选择其中一个选项，则应使用301将对旧网址的请求重定向到新位置。
这也可以，但前提是两个响应的内容类型不同。从描述中，我无法确定是否是这种情况。在这种情况下，我不会定义自定义Content-Type，因此您可以使用内容协商。如果媒体类型没有不同，我不会使用此选项。
答案 3 :(得分：0)
也许选项2 - 标题是Content-Type？
这似乎是以不同格式提供资源的方式;例如XML，JSON，一些自定义格式