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

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

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

阅读 1.8k
评论
    4 个回答

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

    我们目前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

          • 26.6k

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

            撰写回答

            登录后参与交流、获取后续更新提醒

            相似问题
            推荐文章