The current mechanism of content negotiation through Media Types in HTTP draws difficulties on evolving APIs without breaking existing clients. API designer needs to define in a sole place many concerns, often competing each other: semantics for the API responses and client’s requests, semantics for HATEOAS, semantics for API capabilities, semantics for evolving (adding/removing/altering) these capabilities and many more. The result is a very complex specification.
If Software Engineering has learned us something, is that composition can enforce Single Responsibility Principle, if used correctly. Media Types should be broken in smaller components, each describing very carefully a specific functionality of a modern API. The concept of MicroTypes is exactly that: small reusable modules that compose a Media Type.
Microtypes in combination with reactive negotiation, a forgotten but still valid negotiation mechanism in HTTP, can give us enormous possibilities when designing a new API by allowing the API designers to tailor the API capabilities to their needs while at the same time it enables clients to negotiate parts of the API functionality that are only interested or understand and not the Media Type as a whole. Choosing between REST or GraphQL won’t be necessary as APIs can support both styles progressively, simultaneously, or asymmetrically for different classes of clients, using multiple sets of MicroTypes.
High impact blog posts and eBooks on API business models, and tech advice
Connect with market leading platform creators at our events
Join a helpful community of API practitioners
Can't make it to the event? Signup to the Nordic APIs newsletter for quality content. High
impact blog posts on API business models and tech advice.
Become a part of the world’s largest community of API practitioners and enthusiasts. Share your insights on the blog, speak at an event or exhibit at our conferences and create new business relationships with decision makers and top influencers responsible for API solutions.