API consumption is about consumers. It’s about connecting services, synchronizing data among services, and mixing services to make the new end-customer experiences. The purpose of an API is to enable new sorts of consumption for your application services.
Internal applications : Internal microservices that believe functionality exposed by your API’s.
Digital Experience Platforms: Platforms that allow non-technical and semi-technical business users to create experiences for various customers. Grew out of web page management space.
Custom Frontends: Custom web UIs, native mobile, embedded devices, social media, etc.
These three categories of clients have different requirements which will change how you model, build and consume APIs.
An existing API that you’re replacing, trace the source of all the inbound API calls. Your existing API may have clients you never knew about. Then, imagine what sorts of clients you’ll see more of. If you’re selling consumer grocery , many of your future clients will probably be the web of Things devices, like smart refrigerators. If you’re selling apparel, many of your future clients will probably be magic mirrors and similar devices.
Characteristics and Capabilities:
Language: What sort of language are often wont to consume the APIs? Does it need to be plain REST, or are you able to use SDKs supported Java, .NET, or other languages?
Latency: Where physically is that the client relative to the origin of your API? Are you running a custom web UI out of an equivalent physical data center where you’ve got a millisecond of latency, or are you consuming the API from a mobile that’s 200 milliseconds from the origin?
Bandwidth: Similar to latency, what are bandwidth constraints? Your end-consumers will get upset if their smartwatch consumes many megabytes whenever your app is opened.
Processing power: Some clients may have very less processing power, which impacts how you call the API. An internet-connected coffee pot that reorders coffee pods is going to be ready to consume APIs very differently than a microservice running on a replacement data center’s server.
Security: Does your client support the libraries required for common authentication and authorization libraries? Native clients, especially, may severely restrict your ability to incorporate third-party libraries.
Ability to cache: Is the client capable of any client-side caching? To what degree? An internet-connected coffee pot won’t be ready to cache anything, whereas a full data center server can probably cache many many responses.