Describe the API to micro service mapping

[hlgr360]

Since I have seen a few attempts to rebrand SOA style architectures (functional decomposition) as Microservices with REST

to me a microservice represents a domain ... and that domain is seperated from another domain through some constrains ... it could be process (the concept of microflow from the BPEL days) .. or time (changes in one domain are decoupeld from changes in another along time) .. or or ..
it is hard to describe it because I feel that if you look a the context it just pops out to me .. ... for instance SAP is a single domain for me, even though it has plenty of systems inside
I invest time and resources to decouple domains from each other .. this is where an REST API comes into play. A REST API is not cheap .. it costs (design) time and - in most cases - should allow self service (another aspect of decoupling and obtaining more speed) through API management
within a domain there could be multiple services
each interacting with the other .. most of the time I would not use REST between those, but more an IPC style framework like gprot, thrift, protobuf etc ...

I don;t know what I try to get to with this post except maybe spark a discussion and thinking on the granularity of a micro service

it could be a single docker container .. but it could also be 10's of containers

[hlgr360]

Looks like Google is thinking along the same lines: http://apievangelist.com/2017/03/10/api-definitions-covering-both-rest-and-grpc-apis/

having a REST API as public surface but leveraging protobug / gprot as internal API

[hlgr360]

https://cloud.google.com/apis/design/

This guide applies to both REST APIs and RPC APIs, with specific focus on gRPC APIs. gRPC APIs use Protocol Buffers to define their API surface and API Service Configuration to configure their API services, including HTTP mapping, logging, and monitoring. HTTP mapping features are used by Google APIs and gRPC Cloud Endpoints APIs for JSON/HTTP to Protocol Buffers/RPC transcoding.