RESTful Microservices at Silicon Valley Code Camp ’15

Thanks to everyone who came to my RESTful Microservices talk at Silicon Valley Code Camp today. Great turnout and lots of good follow up questions.

You can find the complete slides on slideshare.

Tags: api, codecamp, HTTP, microservices, mytalks, REST, RESTful, SOA, svcc, svcc15

Versioning APIs

I have blogged in the past about microservices, and the advantages that architectural style can bring. These small, focussed and, most importantly, autonomous services commonly expose their functionality via a REST interface.

Inevitably there will come a time when you need to change that interface. Yes, in an ideal world, you will come up with a perfect API first time round and it will never need to change, but requirements change or new users come on board, and we must adapt. Read on to find some approaches to dealing with changing interfaces without breaking clients.

(more…)

Tags: api, cdc, consumerDrivenContracts, HTTP, json, microservices, pact, REST, RESTful, SOA

Rest and Microservices talk at the Las Vegas .Net Group

Thanks to Richard Rosenheim for inviting me to talk on REST and Microservice at the Las Vegas .Net Group today.

If you came along, thanks for attending!

You can find my slides here.

You can also check out my blog posts that the talk is based on:

• An introduction to REST
• Microservices

Tags: architecture, HATEOAS, HTTP, microservices, mytalks, REST, RESTful, royfielding, talks

An intro to Microservices and REST: SoCal Code Camp 2014

If you came along to my session at the SoCal Code Camp, thanks for attending! Any feedback always appreciated.

You can find the slides on slideshare.

You can also check out my blog posts that the talk is based on:

• An introduction to REST
• Microservices

 

Shaun

 

Tags: architecture, codecamp, HATEOAS, HTTP, microservices, mytalks, REST, RESTful, royfielding, socal2014, talks

An introduction to REST

REST, or Representational State Transfer is an architectural style, or more simply, a set of constraints.

We will look at the constraints REST imposes for web apps, but some highlights are:

• Uniform interfaces: all resources are identified by URIs (think: links)
• It relies on a stateless, client-server, cacheable communications protocol (think: HTTP).
• Interaction with resources is via a set of standard methods (think: HTTP verbs)

 

REST can be viewed as a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services protocols (SOAP, WSDL, etc)., but it is much more than that too! It is not an exaggeration to say that REST has been used to guide the design and development of the architecture for the modern Web.

The term REST was defined in 2000 by Roy Fielding in his doctoral dissertation at UC Irvine.

(more…)

Tags: architecture, HATEOAS, HTTP, REST, RESTful, royfielding

Microservices

A microservice is a small, focused piece of software that can be developed, deployed and upgraded independently. Commonly, it exposes functionality via a synchronous protocol such as HTTP/REST.

That is my understanding of microservices, at least. There is no hard definition of what they are, but they currently seem to be the cool kid on the block, attracting increasing attention and becoming a mainstream approach to avoiding the problems often associated with monolithic architectures. Like any architectural solution, they are not without their downsides too, such as increased deployment and monitoring complexity. This post will have a look at some of the common characteristics of microservices and contrast them with monolithic architectures.

(more…)

Tags: microservices, REST, SOA