我只想知道这个过程的高级步骤。下面是我对这个过程的思考:
假设: API返回JSON格式
但是,如果API返回的JSON被更改了怎么办?时不时地检查JSON字符串,然后调整相应的Java类,这真的是一项繁琐的任务。
有人能帮我解决这个问题吗。谢谢
发布于 2016-03-08 23:49:28
使用RESTful API的方法有很多。
通常,您需要知道要使用哪个版本的API。当API更改(即不同版本公开)时,您需要决定新功能是否值得将应用程序迁移到最新的和最大的应用程序.
在我的经验中,迁移到新API总是需要付出一定的努力,这确实取决于这样做的价值(与不这么做相比)和/或旧API是否会被废弃和/或不受发行者的支持。
发布于 2016-03-09 07:41:07
您将描述如何在http上使用json,这很好,因为大多数API都是这样的。但是,如果您对使用Restful资源感兴趣,一种方法是:
media-types才能与其资源进行通信。一些RESTafarians认为,所有的media-types都应该标准化,因此所有客户端都可能支持它们,但我认为这有点过分。
注意链接表示和处理逻辑。media-types不仅描述了数据的格式,而且还描述了如何处理它们。如果它是一个图像,如何显示它,如何运行可能是消息一部分的代码,如何在屏幕上布局,如何使用诸如窗体之类的嵌入式控件等等。media-types头中为此资源指定支持的Accept。Content-Type是否与您接受的media-types之一相匹配(请记住,服务器可以随意忽略您的首选项),然后根据其规则处理返回的表示。
例如,您希望获得客户123456的所有帐户,而这些帐户还没有书签。您可以首先GET用于帐户管理的启动资源。那里的处理逻辑可能描述要链接到的帐户列表。你跟着链接走。那里的表示法可能会给你一个“表格”,你必须填写客户号码和POST。最后,您将得到帐户列表的表示。您可以在这个点上书签页面,所以您不必在下一次遍历整个链。为了完整起见,客户还需要知道其他一些问题:缓存,处理书签(响应3xx代码),下面是表示中的链接。
版本控制是您提到的另一个主题。这本身就是一个完整的讨论,但简而言之:一些人(包括我在内)主张对media-type进行版本化。非向后兼容的更改只需更改媒体类型的名称(例如,从application/vnd.company.customer-v1+json更改为application/vnd.company.customer-v2+json),然后所有内容(例如书签)都会因为内容协商而继续工作。
https://stackoverflow.com/questions/35880146
复制相似问题