防止应用程序更改破坏 API
我有一个应用程序，目前正在编写 API。这是我第一次从头到尾创建一个 API，并且阅读了很多好文章以及如何做到这一点。然而，许多材料专门关注 API 开发（理应如此），但没有找到任何涉及如何确保 API 不会因应用程序项目中发生的更改而损坏的内容。
我的应用程序由一个 ASP.NET MVC Web 应用程序组成，它调用服务层来执行类似 CRUD 的操作。因此，为了获取我的应用程序中所有用户的列表，MVC 应用程序调用服务层并请求它们，并呈现一组用户。我的 API（WCF Web API）也在内部使用此服务层，当我请求用户列表时，我再次返回用户集合（JSON、XML 等）。
但是，如果由于某种原因，另一个开发人员通过将姓氏字段重命名为姓氏来更改底层用户域对象，那么这可能会破坏我的 API，因为服务层将向我的 API 返回一个具有新字段名称的用户对象当它期待别的东西时。事实上，我的 API 确实有自己的对象表示，这些对象在请求时映射到应用程序对象，但此映射不会映射姓氏属性，并将返回为 null。
因此，因为我提供了 API，所以应用程序中的所有更改都必须严格控制吗？如果是这样，那么您是否必须同时更改您的应用程序和 API？如果错过更改怎么办？上述内容对我来说似乎不正确，因此我的帖子是为了寻求更多知识。
同样，我对此很陌生，因此我们将不胜感激。
I have an application which I am currently writing an API. This is the first time I have created an API from start to finish and have read lots of good articles and how to do this. However a lot of that material focuses on the API development specifically (as it should) but have not found anything that touches on how to ensure the API doesn’t get broken by changes which happen within the application project.
My application consists of a ASP.NET MVC web app which makes calls to a Service Layer to undertake CRUD like operations. So to get a list of all the users in my app the MVC app calls the service layer and asks for them and is presented with a collection of users. My API (WCF Web API) also uses this service layer internally and when I request a list of users, again I get back a collection of users (JSON, XML etc).
However if for some reason another developer changes the underlying User domain object by renaming a field say surname to last name then this potentially is going to break my API as the Service Layer is going to return to my API a user object with a new field name when its expecting something else. My API does in fact have its own representation of objects which get mapped to the application objects when requested but this mapping will not map the surname property and will be returned as null.
Therefore do all changes in the app have to be strictly controlled because I provide an API? If so then do you have to change your app and API in tandem? What if changes are missed? The aforementioned doesn’t seem correct to me hence my post to seek greater knowledge.
Again I’m quite new to this so any help on this would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的应用程序不可避免地会发展，如果您可以在应用程序发展时创建新版本的 API 并支持旧版本，然后通知旧 API 何时将过时。
It is inevitable that your application will evolve, if you can create new versions of an API as you applications evolve and support the older versions, then give notice of when older APIs will become obselete.
如果您拥有 API 设计并且您真的不希望任何人污染您的设计。引入专用的 DTO 供您的 API 使用。其是从基础域模型映射的。但即使底层模型频繁更改，您的演示文稿（通过 xml 或 json）也不会更改。
If you are owning the API design and you don't really want anyone to pollute your design. Introduce dedicate DTOs for your API use. Which be mapped from the underpinning domain models. But your presentation (via xml or json) won't change even underlying models change frequently.