public marks

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


The hidden battle between web services: REST versus SOAP

by 2 others (via)
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.

Radovan Janecek: Nothing Impersonal: Mental Exercise

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

Radovan Janecek: Nothing Impersonal: September 2004 Archives

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

REST Eye for the SOA Guy (Middleware Matters)

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

Sam Ruby: Tolerance

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!


» Amazon's SOA strategy: 'just do it' | Service-Oriented Architecture |

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.

Radovan Janecek: Nothing Impersonal: REST and Contract

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

The Cafes » REST vs. WS-*: A Parable

by 1 other (via)
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).

Going Down To The Crossroads…

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

REST wins, no-one goes home []

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.


by 1 other (via)
how to handle an internal product debate around REST vs. SOAP


Connecting Social Content Services using FOAF, RDF and REST

by 7 others (via)
A growing number of "social content" applications such as Flickr,, 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 Browser for REST-style Web Services

by 3 others
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.

What if SOAP had never happened?

by 1 other (via)
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.