Web Service是用XML还是API ｆｕｎｃｔｉｏｎ ｃａｌｌ

hornsay

最近在用Ｃ＃做一个ASP.NET ａｐｐ，　主要功能是把外部的数据通过他们提供的Ｗｅｂ　Ｓｅｒｖｉｃｅ读到自己的ＤＢ。　他们的Ｗｅｂ　Ｓｅｒｖｉｃｅ有用http to request /response via ＸＭＬ, 或者是直接用他们提供的Ｃ＃ＡＰＩ calls.

想听听大家的意见，是用XML好还是直接用C# API Calls?

我个人现在还比较乱,还没有一个头绪. 如果用XML, 市面上好像有MapForce, 可以mapping returned XML 到自己table 结构的XML, 这个做法好像很方便，但如果自己的app 想用 ASP.NET MVC框架, 我不知道这样的组合会不会很乱?

用API call return data到自己build的object好像和MVC的结构比较搭配, 但这样可能会有很多的工作量, 而且未来没有可扩展性, 假如再要去另一个web site读数据， 那要从新再用另一家的API calls, 假如是XML的话就变得很容易，只要增加一个mapping configuration就可以了。

小皇爷

首先，我不是.net 程序员，.net只是做过小项目。我主要是用php的。
但是从你的问题来讲， 我觉得 web service 和API call在本质上是没区别的。都是一个function。 拿到返回的数据后要怎样处理完全是由你决定的。

你说MapForce可以map数据到自己的数据库， 感觉是Mapforce已经wrap好了你要的功能。
至于你说的API,把返回的数据放到自己build的object 什么的， 就是你在写Mapforce的功能而已~

其实问题在于MapForce 是否能很好地满足你要做的功能. 如果MapForce可以做到的话，我会选它。

kr2000

哪个简单用哪个，api的话应该有code example，一般来说简单些

至于扩展性和重用性，无论用哪个方法，我觉得应该另外写个class封装起来
你现有的project就调用这个class的功能就可以了，正如楼上说的，反正就是拿数据，至于怎么拿数据的，现有的代码就不用管了

ysihaoy

个人觉得未来还是rest和json的天下

wkp

XML 首选

espresso76

个人认为 直接 API Call

hornsay

小皇爷 发表于 2012-12-31 14:15
首先，我不是.net 程序员，.net只是做过小项目。我主要是用php的。
但是从你的问题来讲， 我觉得 web servi ...

我对MapForce现在还不熟，看介绍可以从一个XML mapping 到另一个 XML.

我的想法是从return 回来的xml 通过 mapforce 进到自己所要的 xml, 然后再通过datatable进database. 整个过程比较流畅。 而且 XML应该是标准的communication media， 因为未来如果扩展的话，有些website不提供C# API function call， 只有XML, 或者是PHP API function call。

findcaiyzh

现在不都是rest和json了吗？

鱼羊鲜

ding rest和json

LifesoCool

JSON啊~必须JSON

hornsay

LifesoCool 发表于 2013-1-2 14:35
JSON啊~必须JSON

对JSON还不熟，不知道Web Service都提供了JSON？

炸鸡翅

对方的这个web service 是 legacy web service, wcf 还是 asp.net web api?

hornsay

炸鸡翅 发表于 2013-1-2 21:44
对方的这个web service 是 legacy web service, wcf 还是 asp.net web api?

这是一个很大的web site, 提供了．NET的ＳＤＫ，　所以从使用上来说，　用.NET SDK会很方便，但考虑未来其他网站并不提供.NET SDK, 所以觉得是不是未来扩展的话会not consistent？

gooderic1977

我建议用SDK。

首先是快捷，你不需要太多时间来阅读理解对方的API Doc
其次是稳定，对方提供的SDK一定是经过严格测试以后才会release的，自己写代码虽然灵活但是出错的机会大，而且error handling也不好做，特别是对方ws,返回各种代码表示各种状态

虚度

From my perspective, i think the key here is to figure out what your overall integration architecture looks like.

if it's a bit more like a point to point integration, that is, there is not much relationship with other applications with your data ( only used by your app) then direct API call will be a handy/sufficient way to go as I believe it's quicker to design and develop.

if your app falls into a very complex data flow scenario where the data needed to be stored/consumed  frequently, I recon WS may be a better way for you as it provides more scalability. In the long term it also reduce maintenance  overhead

in terms of the actual technology ( ws webservice , REST , JSON), preferably it depends on your internal integration structure as well.

allenoz

xml会比JSON的结构性会强一点，所以现在在大公司的ENTERPRISE系统里，XML还是会比较合适的

mortdale

作为web service的client,你没有很多选择. server提供什么你就用什么,xml还是json不是你决定的. 你提到的Ｃ＃ＡＰＩ calls 应该就是现成的客户端, 是不是再另外写一个客户端要看你自身的需求了. 个人觉得除非有performance issue, 有现成的就要尽量用.

joerkky

同意楼上的，c# api应该是个client library. 我们开发的web service基本也会提供一个restful interface的说明文档和一个client library的。

从api developer的角度讲，我们还是希望用户用client library的，因为：
1. 程序员对写文档都很懒，很多restful interface的文档都是过时的
2. 写client library的一个很大目的是为了避免api用户一直问一直问
3. client library毕竟是api developer自己写的，bug会少一点

bowensyd

web service 一般两种方式读数据，

1. SOAP, 使用的XML格式，overhead多
2.REST，使用Json格式，overhead少

C.D.

webservice本身就是可以应用在不同的技术平台， 脑转大哥一定要。net吗？ 如果支持java的话我帮你写， 现成的web service client java有一大堆， 你想要什么都可以

hornsay

C.D. 发表于 2013-1-22 00:10
webservice本身就是可以应用在不同的技术平台， 脑转大哥一定要。net吗？ 如果支持java的话我帮你写， 现成 ...

谢谢CD.

这个service client本身不难，service provider提供现成的.NET library, 只要拿来call就行了．我是在纠结如果程序将来要用其他的service时，如何保持consistent.

不过我现在暂时会用.NET service library, 比较方便，将来等以后再考虑了，如果没有市场或许也没有将来．

用json来handle REST不错，但这个我不熟，感觉如果需要大量的ｃｌｉｅｎｔ　ｓｉｄｅ　ｃａｌｌｉｎｇ　ｓｅｒｖｉｃｅ, 可能效果不错．我想现在的程序不需要图形，所以server端call　service对performance大概也不会有很大的影响．

wil

service provider提供多种调用选择，使用方也同样可以提供多个调用adapter，只要确保进入domain的api是统一抽象的不会变动就好，domain不该受外部介入方式影响，adapter们乱点没啥，最后实在不行大不了重写一个adapter注入，这样就兼顾了扩展性和灵活性。调用lib担心以后别家提供ws而不consistent，这种命题的反过来也是成立的：调用ws担心别家只提供私有lib。所以不用担心，domain层consistent就好