我有一组soap webservices紧密耦合到同一架构中的应用程序，但我需要它也是其他应用程序的API。
目前，服务使用像这样的参数（和方法）结构
实体GetEntity（int entityId） 实体GetEntityByName（字符串entityName） ......等等。
在创建的情况下我使用： void CreateEntity（实体实体）
我想知道这样做会更好：
EntityResponse GetEntity（EntityRequest requestObj） .....
并且在requestObj中我有id，entityName并且取决于用户提供的内容，我可以执行任一功能。
并且对于创建它将是：
CreateEntityResponse CreateEntity（CreateEntityRequest requestObj）。
我的想法是，通过这样做，API可以在内部进行更改...添加新参数等，而不会立即破坏已经完成的任何集成。
答案 0 :(得分：1)
我认为您可能需要考虑几个设计原则：
1）数据库实体与数据传输对象DTO
看起来那些实体直接来自数据库映射？只是将您的实体公开为API，基本上是一个奇特的SQL查询浏览器。它不一定是错的，但如果您在API中公开DTO，您将获得更好的去耦。 DTO可能比实体更具前瞻性，更通用。
2）SOAP与REST
如果您想要实现最大限度的未来验证，您可能需要考虑REST。使用REST规范，您可以在以后扩展API。 例如，如果你看看像Facebook这样的API，他们纯粹传递参数，然后你会收到你传入的参数的键值映射。所以非常通用。 在SOAP中，您最终会预先定义所有这些最终属性。你基本上需要引入占位符等等。 SOAP肯定是一个很好的契约协议，并且具有代码生成工具更新和更多的优点。但是使用REST，您可以更加灵活，同时放弃SOAP中的一些好东西。
这也是一个非常好的阅读： https://www.mulesoft.com/lp/whitepaper/api/secrets-great-api 或者通常来自Mule的RAML设计规范在设计REST API时是一个非常强大的工具。