A collection of articles about REST – a commonly-cited and frequently misunderstood (IMHO) architectural style for APIs.
October 28th, 2019
Persisting aggregates of AppInsights data in a warehouse can be a useful means of distributing summary information or retaining monitoring data over the long term. You can automate the harvesting of these aggregates using Azure Data Factory.
April 25th, 2018
REST API design is dependent on the clients that will be consuming the resources – APIs that are designed for server-based integrations tend to look quite different from those that are designed to support mobile applications.
March 20th, 2018
If you find REST APIs difficult to design, develop and scale, then your experience with GraphQL is not going to be any easier.
June 4th, 2017
One of the more enduring problems with service integration is managing change in service interfaces. Consumer-driven contracts can help to detect breaking changes, but this visibility comes at a price.
December 12th, 2015
If you’re not using HATEAOS then you’re not using REST. That’s true enough, but in many cases adopting HATEOAS doesn’t deliver much value beyond architectural purity.
October 15th, 2015
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
Change in an API is inevitable. Attempting to manage this change through version numbering usually creates more problems than it solves.
April 20th, 2015
The “big ball of mud” describes a system architecture that is sprawling, sloppy and haphazard. That’s precisely how you’d describe some emerging microservice architectures.
January 4th, 2015
REST is sometimes described as the next “evolutionary step” in service integration. The problem is that REST provides too much of a “dumb pipe” to support genuinely decoupled, fault-tolerant service integration.
November 22nd, 2014
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.
October 15th, 2014
If you adopt OData you don’t have to expose the entire range of query functionality for every resource. You can use the OData libraries to parse queries and interrogate data directly.
August 21st, 2014
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 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
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.
October 19th, 2013
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 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?
December 17th, 2012
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.