【发布时间】：2013-04-24 19:46:44
【问题描述】：
我目前正在从事一个项目，该项目具有发送东西的资源。
假设 URI 看起来像这样 http://api.somename.com/thingssender，只有 POST 动词。
随着时间的推移，这已成为一种资源，在负载中具有几个“可选”元素，这些元素仅适用于发送一种类型的东西。
目前，此资源处理两种不同类型的事物（ThingA 和 ThingB），但子元素中的内容也会有所不同。因此，例如，您可以向一群人发送很多东西或单个东西。
出现了需要 ThingC 的要求。鉴于此端点将来可能会采用负载中包含可选数据的 ThingD，我开始质疑这种“包罗万象”的资源。
我担心资源的复杂性会不断增加，不仅对于开发人员，对于使用 REST API 的客户也是如此。对我来说，这只会造成混乱，并不能创造最佳体验（同样对开发人员和客户而言）。
人们对创建通用端点与特定端点有何看法？
因此，发送 ThingC 的特定端点 (http://api.somename.com/ThingsCSender)。它对我来说是一个单一的责任，并且仔细考虑底层实现不应该导致任何重复的功能。
（给出的示例不是项目中的真实概念或资源：p！）
干杯
【问题讨论】：