当前位置:Gxlcms > PHP教程 > 疑问?同样的api业务逻辑,客户端和WEB需要维护两套api代码吗?

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

时间:2021-07-01 10:21:17 帮助过:53人阅读

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

疑问?客户端和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

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

人气教程排行