If you are building new web services with .NET then OData should be high on your list of frameworks to investigate, especially if you need to support unknown third parties. The technology inherently supports both SOAP and REST style messages with the latter offering ATOM (XML) and JSON representations. This means consumers can pretty much request whatever format is best for them.
A good starting point is Mohamad Halabi’s article Understanding OData v3 and WCF Data Services 5.x. This article goes beyond the standard quick-start guide and instead focuses on the communication protocol itself.
A common misconception about WCF Data Services, Microsoft’s OData implementation, is that it is tied to their ORM Entity Framework. One of the things Mohamad shows you how to do is expose a non-EF data source. For static data this can be as simple as exposing a set of IQueryable properties back by a call to List<T>.AsQuerable. Microsoft refers to this as a Reflection Provider.
For more complex scenarios you may want to refer to the Custom Data Service Providers page on MSDN. It includes links the various interfaces you may need to implement as well as an article by the same name. Unfortunately many of the interfaces are not as well documented as one would like.
When actually setting up an OData service there are some compatibility issues you need to understand. Fortunately Mohamad also discusses the differences between OData V2 and OData V3. The main things you’ll want to pay attention to is how to register a JSONMessageInspector and the difference between JSON and JSON Light. (The latter removes much of the OData metadata.)
WCF Data Services is primarily geared towards providing CRUD style services. By that we mean create, read, update, and delete operations. You can also expose RPC style services such as a ProcessInvoice method. This is done using the WebGet and WebInvoke attributes. Unfortunately there are a lot more limitations than normal WCF services such as “each parameter must be a primitive type”. The Service Operations page covers this in more detail.
Change and query interceptors can be used to rewrite CRUD style requests. Uses range from additional validation and security checks to blocking operations with an error message explaining an alternate operation you wish to be performed.