用web service还是 web api好？

CFree 2015-08-01 10:31:58

asp.net网站数据库中的信息与手机交互，在asp.net平台上开发 web service好还是 web api 好？

...全文

171 回复打赏收藏转发到动态举报

写回复

回复

切换为时间正序

请发表友善的回复…

发表回复

我觉得大部分人都是“眼球动物“，他们关注的往往都是目光所及的东西。对于很多软件从业者来说，他们对看得见（具有UI界面）的应用抱有极大的热忱，但是对背后支撑整个应用的服务却显得较为冷漠。如果我们将整个“生态系统”比喻成海面上漂浮的冰山，我们所能看的到的只是露出水面的冰山一角，水面之下才是一个“庞然大物”。提到服务，我们自然想到Web Service。但是传统意义上的Web Service却有点名不副实，因为支撑它的其实不是Web而是SOAP，承载一个Web Service甚至可以根本不需要Web。随着互联网的普及，互联网应用（尤其移动互联网应用）已经成为主流，“SOAP之重”已经越来越令我们无法承受，于是采用REST架构风格并直接采用Web进行通信的轻量级Web Service走进了我们的视野并登堂入室。为了与传统的基于SOAP的Web Service以示区别，我们将后者称为Web API。很多人鼓吹SOAP已死，我个人对此持不同的看法。上面讲的“重”与“轻”都是不带任何感情色彩的中性词，至于优劣评价则决定于它们是否适合应用的场景。到目前为止，对于企业级应用之间的内部集成互联，我觉得传统的Web Service依然是最好的选择。传统Web Service应用的领域貌似在不断被Web API占据，但是后者并不能完全被视为前者的替代品，它只是让“踩过界”的Web Service退回到它应该坚守的领地。Web Service和Web API在各自适合的领域各司其职，使“路归路、桥归桥”是一种理想的状态。 Web Service和Web API的合理布局同样也体现在微软技术平台上。WCF在过去是唯一的选择，这是一个具有“SOAP”基因的通信平台，微软后来利用扩展让它提供了针对REST的支持。正因为如此，如果使用WCF来构建Web API的话，我们依然需要采用传统的编程方式，Web API的“简单、快捷”完全得不到体现。微软意识到在一个“重量级”通信框架上通过扩展实现“轻量级”的通信，还不如重新构建一个通信平台，于是ASP.NET Web API应运而生。

通过此可以对android调用webservice有一个更深刻的认识

Velocity是一个基于java的模板引擎（template engine）。它允许任何人仅仅简单的使用模板语言（template language）来引用由java代码定义的对象。当Velocity应用于web开发时，界面设计人员可以和java程序开发人员同步开发一个遵循MVC架构的web站点，也就是说，页面设计人员可以只关注页面的显示效果，而由java程序开发人员关注业务逻辑编码。Velocity将java代码从web页面中分离出来，这样为web站点的长期维护提供了便利，同时也为我们在JSP和PHP之外又提供了一种可选的方案。 Velocity的能力远不止web站点开发这个领域，例如，它可以从模板（template）产生SQL和PostScript、XML，它也可以被当作一个独立工具来产生源代码和报告，或者作为其他系统的集成组件使用。Velocity也可以为Turbine web开发架构提供模板服务（template service）。Velocity+Turbine提供一个模板服务的方式允许一个web应用以一个真正的MVC模型进行开发。

javax.servlet的jar包，解决找不到javax.servlet.*等问题的！欢迎下载！！

10个ASP.NET例子打包项目实例完整源码

29,043

社区成员

12,461

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章