RESTful API vs Microservice

  • is easy to understand / modify (because they are small)
  • is the only place having logic/business rule
  • does not expose any implementation details such as database to ensure loosely coupling; it also implies that the RESTful APIs or Functions that implement Aggregates within a bounded-context should belong to one Microservice because they are tightly coupled in terms of sharing lots of same high level design and architecture, i.e. programming language and frameworks, database access framework, etc. to reduce the complexity as you may not want to maintain a module or bounded context (i.e. Messaging service) that uses different technologies and tech stacks
  • can be deployed separately without affecting others as long as the interfaces stay same
  • a few more benefits (such as scale separately, choice of programming languages, etc.)
  • trade development complexity for boring but difficult operational complexity, i.e. cross-cutting concerns such as service discovery, service-to-service and origin-toservice security, observability (including telemetry and distributed tracing)
  • is truly loosely coupled (as long as the interfaces and their semantics keep same, the API’s implementation on the server can change anytime without worrying about breaking its consumers and consumer side deployments)
  • is language-agnostic

--

--

--

Passionate Technologist and Continuous Improvement Practitioner

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Eric Huang

Eric Huang

Passionate Technologist and Continuous Improvement Practitioner

More from Medium

Siren Song

Outbox pattern, bridge OLTP and OLAP

Building Resilient Microservices — A Guide for TPMs

Redis: Cache Invalidation Done Better