DX, API Design & Documentation

API Links For Every UI Element

311views

I’ve showcased ClokudFlare’s approach making their API available as part of their user interface several times now. It is a practice I want to see replicated in more desktop, web, and mobile applications, so I want to keep finding new ways of talking about, and introducing to new readers. If you sign up or use CloudFlare, and navigate your way to their SSL/TLS section, you will see a UI element for changing the levels of your SSL/TLS encryption, and below it you see some statics on the traffic that has been served over TLS over the last 24 hours. Providing you full control over SSL/TLS within the CloudFlare UI.

At the bottom of the UI element for managing your SSL/TLS you will see an API link, which if you click you get three API calls for getting, changing, and verifying the SSL/TLS status of your domain. Providing you with one click access to the API calls behind the UI elements, giving you two separate options for managing your DNS.

This is how all user interfaces within applications should be. The API shouldn’t just be located via some far off developer portal, they should be woven into the UI experience, revealing the API pipes behind the UI at every opportunity. This allows for the automation of any activity a user is taking through the interface using the platform’s API. You could also consider embedding a simple Postman Collection for each API capability, allowing a user to run in Postman—to further support, you could also make a Postman environment available, pre-populated with a users API Key, making execution of each platform capability outside of the platform possible in just one or two clicks.

Once each UI capability is defined as a Postman collection it can immediately be executed by a user in a single click. It can also be executed using a Postman runner as part of an existing CI/CD process, or on a schedule using a Postman monitor. This extends the reach of any UI feature, making it portable, sharable, and executable outside of the UI by any consumer. Can you imagine if all UI elements had this approach baked in by default? If every UI element was API-driven and had a link to the API call behind, with an environment that provides the user context which the API call should be ran. This would change the API game, making APIs more about single use execution and automation, even before they are used within other applications—drastically changing who APIs serve.

This article originally appeared here.

Kin Lane
Kin Lane is a writer, storyteller, and recovering technologists. Kin is the Chief Evangelist at Postman, and is helping share the story of how Postman is the next generation of API development environment (ADE), while also continuing to tell API stories on API Evangelist about what is happening across the API sector.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture