PUBLIC MARKS from nhoizey with tags "web services" & rest

Almost everyone has at least heard of SOAP. Few people have heard of REST. But both are jockeying for the mindshare of developers trying solve problems building applications on the web. REST by virtue of existing, and SOAP largely by virtue of backing by software vendors and standards bodies.

Is HTTP GET/POST enough for you? Fine. Then you are simply not the 'right target' for web services evangelists ;-)

Will there be still 97% of simple REST services on the web then? Yes, sure. WS-* does not compete with browser-oriented applications or simple-get-then-do-regexp interactions

my latest Internet Computing (IC) Toward Integration column tries to take a middle ground in the ongoing "REST vs. SOA" debate. It's called "REST Eye for the SOA Guy" (PDF) and it attempts to explain, from the perspective of someone like me with a lengthy SOA background, the benefits that REST brings to the distributed systems picture

acceptable levels of tolerance differ depending on whether or not a given operation is safe or not

to implement Web Services Security with the X.509 Certificate Profile, you also need to implement XML Signature (which includes XML Canonicalization and XML Exclusive Canonicalization) and XML Encryption. To correctly handle imports of WSDL1.1 documents (and validate the traffic they describe), you need to support the entire behemoth that is XML Schema -- in particular if you are attempting to support RPC-oriented SOAP, which informally requires you to support the entire XML Schema Datatypes specification. Don't forget support for SOAP with Attachments, either!

It doesn't matter if a partner uses REST or SOAP, he pointed out. "Our developers don't care if it's REST or SOAP. It's all about customers," he said.

I see lack of contract as the main issue and perhaps even showstopper in enterprise

A couple of years ago Water Supply-Strategic Tactical Air Recycling (WS-STAR) opened up a branch in our town. WS-* (as my IM crazy kids would type) came about from the merger of Secure Operations Air and Power (SOAP) with Expert Machine Lubrication: Radiators, Power, and Cooling (XML-RPC).

catalog what resources MS has already committed to the XML/HTTP/REST technologies

Let’s be realistic. No software architecture can truly withstand implementation. REST is really great, but on the web, there is plenty of detail work to be cleared out, like push, containership, encoding, side-effected GETs, curse-of-popularity, queuing, 2 versus 4 methods, universal format junk, and authentication, among others. I could go on, it’s messy out there.

how to handle an internal product debate around REST vs. SOAP

Traduction française des articles de Joe Gregorio sur REST

A growing number of "social content" applications such as Flickr, del.icio.us, audioscrobbler, and AllConsuming are making open web services part of their core offering to end users. These interfaces allow users to query, share, and manipulate the data managed on their behalf by these social content applications.

RESTGate is a Web-based client for REST-style Web Services. Any Web browser can be used to send arbitrary HTTP GET requests by manipulating the URL. It used to be necessary to write an HTML form or a small program to send POST, PUT and DELETE messages. Now, RESTGate allows you to send POST, PUT and DELETE messages to a RESTful Web Service and to inspect the response messages.

SOAP and its ever-growing family of specifications emerged because vendors needed something more concrete than design services to sell their customers, and because the hype wave around XML had promised too much that couldn't be delivered immediately.

Un peu de tout dans cette nouvelle chronique de Alain Lefebvre

Le Wiki de REST