作为开发人员，我们是否正在尝试使用 REST 将方钉放入圆孔中，还有其他解决方案吗？
最近，我的任务是采用 SOAP/REST 时代之前的旧 Web 服务，并使其达到当前 Web 服务“标准”的标准。这是非常直接的服务，HTTP(s) POST XML，执行操作并使用 XML 进行响应，这是一种非常面向消息的服务。
“Web”服务的两个最流行的选项是 SOAP 和 REST...
虽然从技术上讲 SOAP 非常适合我的应用程序，但它感觉相当笨重，并且没有真正需要 WS-* 功能。我的意思是，好吧，它确实执行 SSL 和简单的用户名/密码身份验证，但是 WS-*!@$@$@1!!!谁需要它？好吧，至少不是我，我对那些这样做的人表示哀悼（我确信在正确的情况下，这是一项很好的技术；））
现在我喜欢 REST，因为它看起来很轻量。事实上，我能够采用非常流行的 REST 框架（例如 Jersey）并实现 Web 服务的每个功能。事实上，我成功地将代码库从数千行代码减少到了 100 行代码。很明显，旧服务中需要进行大量手动工作来解析 XML 并映射到正确的函数调用等……
REST 有什么问题吗？
在高水平上？没什么（你可以坐下来争论利弊，直到牛回家为止）。这篇文章/问题并不是 SOAP 与 REST 之间的激烈战争。但为什么大多数人选择走这条路呢？
尽管我能够使用 Jersey 和 REST 实现 100% 的服务，但我几乎设法打破了“REST”的所有规则（如果有的话）。
- 它不提供命名资源
- 它不可缓存
- 它比 CRUD 更复杂
- 一切都是 POST
- 一切都返回 200 OK
但它工作得很棒！ :) 但我违反了规则 :P
举个例子，我的应用程序有数百个“错误”代码。 REST 人员喜欢说映射到 400 Bad Request 并将原因放在正文中。但我想说的是，既然我可以简单地返回 XML 响应中的代码，那为什么还要麻烦呢？当客户（开发人员）可以简单地解析一段代码时，为什么要让他们感到困惑呢？
因此，如果 SOAP 很重，而 REST 似乎更面向 CRUD 和面向资源的应用程序类型，那么轻量级“Web”服务有哪些选择？ XMLRPC？为什么人们执着于 REST 还是我错过了什么？
让乐趣开始吧！ :)
Recently I was tasked to take an old web service pre SOAP/REST era and bring it up to par with current web service "standards". It's pretty straight forward service, HTTP(s) POST XML, do stuff and respond with XML a very message oriented service.
The two most popular options for "web" services are SOAP and REST...
Though technically speaking SOAP would fit my application perfectly, it feels quite heavy handed and none of the WS-* features are really needed. I mean OK it does do SSL and simple username/password auth, but WS-*!@$@$@1!!! who needs it?! Well not me at least and my condolences for those who do (I'm sure in the right scenarios it's fine piece of technology ;))
Now I like REST because it's seems lite-weight. In fact I was able to take a very popular REST framework like Jersey and implement every single feature of the web service. In fact I managed to reduce the code base from thousands of lines of code to couple 100 lines of code. The obvious being lots of manual work was being done in the old service to parse the XML and map to the right function calls etc...
Whats wrong with REST?
On a high level? Nothing really (You can sit and argue the pros and cons till the cows come home). And this post/question isn't a flame war of SOAP vs REST. But why is it that most chose to go down this route?
Though I was able to implement 100% of the service using Jersey and REST I pretty much managed to break all the rules of "REST" if there are any.
- It doesn't serve named resources
- It's not cacheable
- It's more complex then CRUD
- Everything is a POST
- Everything is returned as 200 OK
But it works fantastic! :) But I'm breaking the rules :P
One example, my app has hundreds of "error" codes. The REST guys like to say map to 400 Bad Request and put your reason in the body. But I say why bother when I can just simply return the code in the XML response. Why confuse the client (Developer), when they can simply parse one code?
So if SOAP is heavy and REST seems more oriented for CRUD and resource oriented type of applications, what are the options for lite-weight "web" services? XMLRPC? Why are people square pegging into REST or did I miss something?
Let the fun begin! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您乐意重新发明一个经过考验的分布式应用程序协议（例如 HTTP），那么请随意。
更快。
If you are happy re-inventing a tried and tested distributed application protocol like HTTP then feel free.
quicker.