我们将要创建一些RESTful服务,这些服务本质上将成为一些基于SOAP的Web服务的传统.SOAP服务更通用,将在整个组织中使用(至少是计划).RESTful服务专为特定客户量身定制.这个决定已经做出,不幸的是我无法改变......
我们正在努力解决如何以一种有意义的方式构建RESTful资源,遵循REST最佳实践,并调用这些SOAP服务而不会给自己造成太大的痛苦.
我们对后端服务的粒度级别有一些自由,但普遍的共识是:保持粗糙度并且不根据特定客户的需求定制它们.
这导致了一些有趣的问题.例如,如何处理父母的子资源.我们一直在使用的典型示例是:具有子地址的客户.
我们有一个后端SOAP服务,它将客户更新为整个实体.但是,REST服务客户端可能只需要更新帐单地址.我们如何最好地处理子资源的后续更新？
我们应该在"父级"(客户)进行更新,还是公开一个更细粒度的REST操作,将地址视为资源并以这种方式更新？后者似乎是正确的,RESTful方式.但是,如果我们这样做,我们基本上只会为一个更新调用粗粒度的后端服务.似乎没有意义,因为它是一个非常重量级的电话.
我们还在努力解决如何将RESTful资源与我们的后端域模型相关联的问题.我们可能将RESTful资源视为单个实体,但在后端的域中,它可能是许多不同的实体.我们现在有一个相对简单的数据库表来处理这个问题,但是当我们将越来越多的资源映射到域对象时,我不相信它会扩展.
这些只是我们所遇到的事情的几个例子......我想知道是否有人遇到类似问题并且有任何建议或可能能够指出一些可能有一些最佳实践的文章.
看起来这不是一个不寻常的问题,随着越来越多的应用程序使用RESTful架构,它将变得更加相关,但我似乎无法找到任何其他信息.
非常感谢!