x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!
  • How REST replaced SOAP on the Web: What it means to you

    by Ross Mason on  Oct 20, 2011 16

    The number of REST APIs has grown dramatically over the last 5 years. However, most developers are still struggling to find an agreed upon definition of a RESTful Architecture leading to a lot of inconsistencies in the way these APIs are implemented. This article details how Mule iON, an Integration Platform as a Service, provides a consistent way to expose APIs and API mashups.

  • Is REST the future for SOA?

    by Boris Lublinsky on  Aug 11, 2011 60

    In this article Boris Lublinsky discusses architectural difference between SOA and REST and discusses different approaches for leveraging REST in SOA implementations

  • Interview With Ross Mason On The Release Of Mule 3

    by Dilip Krishnan on  Nov 16, 2010

    Mulesoft recently released Mule 3, their next generation ESB platform. The product comes with a lot of architectural changes under the hood to support the features aimed at making the product easier to use, such as Mule Cloud Connect and Flow, a message flow based service design. InfoQ caught up with Ross Mason to learn more about the product release and the new features in the product offering.

SOA Master Data Management in .NET 4.0

Posted by Sebastien Jehan on  Jul 06, 2010

.NET 4 introduces several tools which help build an application-independent SOA data repository. This article explores those tools and how they help make SOA data services flexible and unintrusive. 2

Flexible and User-configurable Charts with Flash Builder Backed by a Java-based RESTful API

Posted by Daniel Morgan on  Jul 01, 2010

Daniel Morgan shows how to build a portal-style application with user-configurable charts assembled using Adobe Flash Builder 4 connecting to a Java RESTful API for their data.

Nobody Needs Reliable Messaging

Posted by Marc de Graauw on  Jun 18, 2010

Are transport-level reliability mechanisms like WS-ReliableMessaging really needed? Marc de Graauw asserts that business-specific logic for in-order and exactly-once processing do the job much better. 32

Resource-Oriented Architecture: Information, Not Containers

Posted by Brian Sletten on  May 03, 2010

New technologies are emerging to make it easier to encode extractable content on the Web. This article focuses on how producers can increase the machine-processability of the documents they produce.

Using DNS for REST Web Service Discovery

Posted by Jan Algermissen on  May 03, 2010

Jan Algermissen explains the need for discovery of RESTful services, and explains how the existing Domain Name Service (DNS) standard can be used as a widely-deployed and scalable solution. 18

REST and SOAP: When Should I Use Each (or Both)?

Posted by Mike Rozlog on  Apr 01, 2010

SOAP and REST both work, and both have pros and cons around interfacing to web services. But, it is up to the web developer to make the decision of which approach may be best for each particular case. 24

Resource-Oriented Architecture: Resource Metadata

Posted by Brian Sletten on  Jan 22, 2010

Brian Sletten discusses the benefits of REST, what a resource is, associating metadata with a resource, the pitfalls of common models of resource metadata, SPARQL, RDF, RDF triples, and querying RDF. 6

Book Excerpt and Interview: Dynamic SOA and BPM: Best Practices for Business Process Management and SOA Agility

Posted by Boris Lublinsky on  Dec 21, 2009

Boris Lublinsky interviews Marc Fiammante as part of a review of Marc' new book, Dynamic SOA and BPM: Best Practices for Business Process Management and SOA Agility.

Decoupling REST URLs from Code using NetKernel Grammars

Posted by Randolph Kahle on  Dec 15, 2009

Randolph Kahle explores the challenge of combining the potentially fluid world of URLs with the more static world of deployed code using NetKernel grammars for inbound and outbound URL binding. 2

General Feedback
Editorial and all content copyright © 2006-2014 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy