Web services

July 12th, 2016

Simplifying .Net REST API development: Nancy, self-hosting and ASP.Net Core

REST API development using ASP.Net WebAPI is so fussy compared to other ecosystems such as Node.js and Ruby. New frameworks are emerging that promise to simplify both development and hosting of APIs in the .Net world.

October 15th, 2015

Using the REST API connector as a data source in Informatica Cloud

It can be pretty straightforward to read REST API resources using Informatica Cloud – so long as you know which levers to pull and your data is in a sympathetic format.

September 27th, 2015

REST APIs don’t need a versioning strategy – they need a change strategy

Change in an API is inevitable. Attempting to manage this change through version numbering usually creates more problems than it solves.

November 22nd, 2014

The RESTafarian flame wars – common disagreements over REST API design

Debates on the finer points of REST can bring out the worst in people as they seek to define what is and is not “RESTful”. In most cases the debate is unlikely to make the difference between success and failure for an API.

August 21st, 2014

Messaging shouldn’t be used for queries

When developers first start using messaging they can be tempted to use it as a brand new hammer for every nail. Messaging brings a lot to the party, but it isn’t necessarily a suitable transport for fast, synchronous query processing.

July 22nd, 2014

Using a tolerant reader for web service integrations in .Net

Using version tolerant readers can help you to cope with changes to service contracts though this does come at the expense of a weaker contract. The approach is more appropriate for fluid services that are prone to frequent change.

April 21st, 2014

Hackable URIs may look nice, but they don’t have much to do with REST and HATEOAS

Structured and “Hackable” URIs are a staple part of SEO-friendly websites. Although developers generically expect to see them in HTTP-based APIs, they should be irrelevant to consumers of a fully RESTful API that leverages HATEOAS.

February 6th, 2014

Comparing Web API 2 and WCF for building services on HTTP and REST

On the face of it, Microsoft took WCF’s promise of “one implementation, any protocol” and shot it in the head with ASP.NET Web API. Now that the Web API has matured a little it is easier to see them as complimentary technologies that deliver very different types of service.

October 19th, 2013

Can APX help in developing usable and accessible APIs?

Given how important APIs have become in driving the reach of applications and services, it’s surprising how little investment is made in the usability of APIs as opposed to UIs. Perhaps the principals and techniques used by UX should be applied to developing more effective APIs…

June 17th, 2013

Netflix has abandoned OData – does the standard have a future without an ecosystem?

Netflix have closed their OData catalogue and EBay seem to have quietly put their implementation out to grass. With a shrinking ecosystem and no marquee services, does Microsoft’s data standard have a future?

June 4th, 2013

Sharing web services and APIs in an organisation: challenges and pitfalls

Sharing services and APIs can appeal to a desire to reduce duplication and improve development efficiency. It’s a worthy ambition though the journey there can be littered with costly traps for the unwary.

December 17th, 2012

REST services may not have standards, but they should follow conventions

REST is more of an architectural style than a set of standards. That said, a service should follow certain conventions if it is to be predictable and simple to work with.

September 21st, 2012

Contract-first web service development using WCF and .Net 4.5

Contract first service development in .Net has always been hampered by the limited availability of any appropriate tooling. The new Contract-First tool in Visual Studio 2012 is only a partial solution.

August 16th, 2012

What makes a good web service API?

On the face of it, the demands of a good web service interface are pretty much the same as for any other API. You just need to make it useful, reliable, easy to use and fast. However, public-facing APIs are forever so it’s vital that you get it right the first time.