2

鉴于 REST-ful Web 服务

/product/{product-id}

返回 Content-Type 的 Product XML 文档

x-esvc/product+xml

我也需要支持

x-esvc/prices+xml

（x-esvc 是自定义 MIME 类型；产品和价格是两个子类型，+xml 暗示它是基于RFC 3023的基于 XML 的格式）

问题是第二种格式是否应该有自己的网络服务

/prices/{product-id}

...或者我是否应该使用内容协商和 Accept HTTP 标头来区分现有产品 Web 服务中的两种格式？

请注意，仅涉及一个真实实体（产品），并且“价格”是 OO 术语中的依赖对象列表。但是，在这两种情况下都可以使用相同的标识符。

表述该问题的另一种方法是“价格”是否可以被视为同一资源的不同表示，或者如果信息不同，是否应该将其视为另一种资源？

我确实知道内容协商通常用于区分同一图像的不同技术格式，例如 JPG 和 PNG。即信息相同但格式不同。在这种情况下，内容协商将用于区分同一实体的不同信息。

这会是 REST-ful Web 服务中对 Content Negotiation 和 Accept HTTP 标头的有效使用吗？

4

1 回答 1

0

我喜欢不同的网络服务。它简化了任何消费者的使用，因为可以通过单独指定 url 来完全表达请求。这在您项目的当前阶段可能无关紧要，但可能会随着它的发展而改变 - 组装和维护 Web 服务调用更容易，而不必摆弄请求标头。

如果您不需要/想要这种分离服务器端，您仍然可以通过 Web 服务器配置中的指令统一两个 url 位置。

操作 Web 服务也可能变得更容易：想想负载平衡和维护停机时间。

根据您的项目规模，您的里程可能会有所不同。对于一些内部 PoC，你可能最好坚持你所拥有的。

于 2013-03-13T13:55:49.400 回答