疑问？同样的api业务逻辑，客户端和WEB需要维护两套api代码吗？

前提：业务内部已经拆成多个微服务

疑问？客户端和WEB需要维护两套api代码吗？如果只维护一套api,采用跨域或服务内部转发合理吗？

回复内容：

前提：业务内部已经拆成多个微服务

疑问？客户端和WEB需要维护两套api代码吗？如果只维护一套api,采用跨域或服务内部转发合理吗？

我是以讨论的方式回答此问题的

我们目前APP和WEB(PC和移动网页)尽量都用同一套API，我们现阶段也也没有封装那么多的微服务，所以应用层和服务层没有明确的隔离都统一叫做数据API！也是和你一样考虑到维护成本问题，所以即使APP首页和网页首页 UI一样的情况下，为了提高APP数据加载速度可能把需要N个请求在API层包装成了一个独立的API再调用一次公共API一次性返回所有首页需要的JSON数据，除了某些下拉才加载的数据!

另外你说的跨域我感觉，你是想用AJAX去直接请求你们的服务API，这个我感觉不合理，必须在项目中用后端语言再调用一次数据API，这样就不存在跨域问题了也更安全，相当于你的客户端项目就是你的应用层了!

我们最近也碰到了一个纠结的问题，IOS在审核期间的时候，新的API必须发布，但是我们就算从业务角度决定不兼容老版本，在审核期间IOS老版本还是会请求出错，所以我们想了两个都不算特别好的方案，一个是程序角度做逻辑兼容，对于新人来讲绝对是一个灾难，另外一个是永远让APP的版本对应一套API版本，这样物理上代码就会多出一份，源码很臃肿比较头大，所以借此贴欢迎一起讨论API多版本维护问题！

一般来说，现在采用restful Api设计模式， 只需要维护一套api, 客户端通过跨域请求来访问api。

不需要，只要维持相同的api认证方式即可，比如访问接口需要带上access_token

不管你用跨域还是内部转发都是凑合方案，既然你的系统已经拆成了两块，那接口自然也是两个独立的接口，而客户端也应该独立的去调用不同的接口。不管你现在直接做还是先用凑合方案解决，终究还是要独立出来的，不然两套系统如何解耦？那不和不拆一样了吗？