This series takes the reader on a journey from determining the business case for APIs to a design methodology, meeting implementation challenges, and taking the long view on maintaining public APIs on the Web over time. Along the way there are interviews with influential individuals and even a suggested reading list on APIs and related topics.
What are the practical concerns associated with running microservice systems? And what you need to know to embrace the power of smaller services without making things too hard? At last GeeCon 2014 in Krakow, Sam Newman tried to answer those questions by giving 14 tips about how microservices can interface, how the can be monitored, deployed, and made safer.
Ganesh Prasad proposes minimizing service dependencies in a SOA implementation rather than avoiding point-to-point connections in order to obtain a more flexible system that can evolve over time. 1
Apache CouchDB is a Document NoSQL database that uses JSON for storing documents. In this article, Jan Lehnardt gives an overview of CouchDB, its architecture and what problems it aims to solve. 3
The n+1 one problem doesn’t just affect ORMs, any kind of Web API can suffer from the same performance problems. Ali Kheyrollahi discusses some of the ways to identify and correct n+1 scenarios.
This article describes the increasingly popular Microservice architecture pattern, used to architect large, complex and long-lived applications as a set of cohesive services that evolve over time. 13
Val Huber explains creating a RESTful API from an existing database schema, extending the API to define multi-table hierarchical resources, and adding behavior using declarative reactive expressions. 2
Currently, Antifragility and Microservices are trending topics and this might be a hint that there are new architectural paradigms or design patterns on their way for building application systems.
We demonstrate how to build a RESTful API on top of CQRS systems. The result joins HTTP semantics and REST style with distributed computing concerns such as eventual consistency and concurrency. 7
This article (the second in a four-part series) focuses on the design of a hypermedia server based on the API designed for the class scheduling problem domain outlined in part one of the series. 1
This article (the first in a four-part series) focuses on the design of a hypermedia type, by mapping a particular problem domain to hypermedia messages, as a basis for the API. 1