Embedded Files
Graphical User Interfaces are designed for humans and APIs for softwares.
An API is an interface that allows applications to interact with each other.
Client - Server
Client - API - Server
API defines a standard specification which the Client and Server must adhere to, to exchange data.
All APIs have their own sets of agreed-upon standards known as the API's contract.
APIs allow you to outsource key data and functionality through a predictable standard interface.(Ex: Using Google maps to provide store information/directions on your Retail Store mobile app. Develop the functionality but eave the data to Google to handle)
APIs serve as a layer of abstraction between the data or function being provided and the logic required to complete and run a task at the source. In other words, your software just needs to know how to connect to the other system, not how the other system works.
Increased Developer Productivity
When programmers write code, they rarely start from scratch. APIs are designed to take an existing code base and use it whenever, wherever instead of attempting to re-create those features. While reusing existing code limits differentiation between developers, a reference to the API (more commonly referred to as calling an API) can supply it with the expected data. Given how APIs can handle common tasks, and can even handle not-so-common tasks, APIs can minimize application development time from months, or even years, to weeks.
APIs use HTTP Verbs
POST
Submit requested data to a server for processing
GET
Retrieve requested data from a server
PUT
Update and replace existing data with new data being sent in the request
DELETE
Remove the requested data from the server
In most cases, the service provider provisions a special web address known as an API endpoint for the software to connect to using an HTTP verb. Here’s an example of an endpoint from FitBit.
Think of endpoints like sockets that consuming applications plug into.
GET https://api.fitbit.com/1/user/[user-id]/activities/date/[date].json
Applications aren’t limited to using one API at a time! An application can make calls to multiple APIs and API providers. These composite applications are sometimes called mashups.
API Considerations -
Design, Scalability, Reliability, Security and Documentation.
https://www.programmableweb.com/news/api-godai-5-elements-amazing-api/analysis/2016/11/10
https://trailhead.salesforce.com/en/content/learn/modules/api_basics
The number of applications that can take advantage of the data abstracted by an API’s endpoint is limited only by the imaginations of developers and the capacity of the API provider’s infrastructure.
Case in point: It wasn’t long after Google offered an API for Google Maps that thousands of third-party developers stepped forward with unique and innovative applications that consumed the API, incorporating Google’s mapping functionality directly into their apps. Think Yelp, Lyft, Tesla, and any other application that provides a map with the Google copyright in the corner.
API Economy
Depending on the volume of calls, a provider like Google might charge the application developer a fee for using the API. This gives rise to the idea of an API economy.
Back in the days when Unix first came out, it was not uncommon for programmers to remotely invoke business logic from another machine across a network through a technology called RPC, or remote procedure call.
Are you ready for some serious acronym soup? Over time, RPC’s gave way to other forms of remote data and functionality request such as Network DDE (dynamic data exchange), CORBA (common object request broker architecture), electronic data interchange (EDI), and so forth. Eventually, something called XML-RPC (woo hoo! RPC again!) surfaced, which later evolved into what we now know as web services, based on XML and the simple object access protocol (SOAP).
Web APIs(or just APIs) versus the new API-like tech :
There are now two relatively new API-like technologies that part ways with the currently favored web approach. One comes from Facebook, called GraphQL, and the other is from Google, called gRPC.
Both have their own advantages over current web APIs. For example, GraphQL is inspired by the idea of a social graph and how different data items like friends, photos, places of work, and so on, form labyrinth of interrelated information. GraphQL makes it possible to request information from across an entire graph of data at once (versus the multiple round-trips of requests it takes traditional APIs to accomplish the same thing).
gRPC on the other hand has its own advantages. It relies on HTTP/2 (HTTP version 2) which can stream data bidirectionally. gRPC can also turn an API into a streaming API that feeds its data to the consuming application as soon as that data becomes available. For certain real-time applications like a stock market ticker, that’s a much more efficient way of getting data as opposed to forcing the app to constantly check if there’s new data available like traditional APIs do.
the idea of web APIs is really about turning a business capability into a networkable service that other applications can remotely use. How those applications call those APIs is something that has changed more times than we can count over the years, and judging by the direction of things, it will continue to evolve
https://www.programmableweb.com/api-university/understanding-api-first-design
API-Led Connectivity to the Rescue
API-led connectivity is a methodical way of connecting applications, data, and devices through APIs. When the entire organization adopts API-led connectivity, developers and system architects are empowered to deliver applications and projects that avoid tightly coupled point-to-point integrations, in favor of:
Clear contracts between systems
Reusability
Discoverability
Visibility and security
Availability and resiliency
They are building the foundation of an application network—a seamless framework of applications, data, and devices connected by APIs. Businesses with application networks have a plug-and-play repository of assets that they can use in an agile way.
There are a lot of terms to keep track of! Here’s a handy table to help you keep some major concepts straight and top of mind.
source : https://www.mulesoft.com/resources/api/advantages-of-api-led-connectivity
API-led Connectivity
A methodical way to connect applications, data, and devices through reusable and purposeful APIs; the opposite of point-to-point integration.
Application Network
A network of applications, data, and devices connected by reusable APIs, each built with the principles of API-led connectivity.
Anypoint Platform
MuleSoft's platform that provides many tools to design, build, deploy, and operate the application network.
MuleSoft recommends building and organizing APIs into three broad categories.
System APIs
Process APIs
Experience APIs
Think of these three layers of APIs as an example architecture to implement API-led connectivity, where each layer serves a specific purpose.
System APIs handle the minutiae of connecting to systems (think databases) such that users are insulated from any changes.
Process APIs shape data across System APIs, with the intent of modeling business needs and processes, to break down technology silos and make data more consumable. [ORCHESTRATION]
Experience APIs reconfigure this data so that it is most easily consumed by its intended audience through apps and devices. APIs at this level are created with reusability in mind, without a dependence on the source systems from which that data originates.
In other words, the MuleSoft Anypoint Platform provides a suite of tools to create these different kinds of APIs designed to either unlock data from systems, compose data into processes, or deliver an experience. Rather than being tightly coupled, they are loosely coupled components that can be reused to connect different systems.
Anypoint Platform and the Development Lifecycle
We can break down Anypoint Platform into the following components.
MuleSoft has the Anypoint Exchange. Here you find a public repository of connectors, templates, examples, and APIs. Unlike the AppExchange, these aren’t ISVs selling their wares. The public-facing segment of the Anypoint Exchange is 100 percent free!
In the open source spirit, this is where developers share their design patterns and best practices. This includes everything from reusable fragments of API definitions to full-fledged examples.
When you are ready to design, develop, and test, the Anypoint Design Center has you covered. It includes tools such as API designer, Studio, and Flow designer. Using these tools, developers can:
Design, document, and test APIs in a web-based graphical environment.
Use API specifications to scaffold the API implementations, automatically generate documentation, or mock (simulate) an API.
Build integrations and implement APIs in a low-code environment in your browser or desktop.
Create data transformations within a drag-and-drop interface or by writing the code.
Test integrations manually or automate tests locally or in continuous integration/continuous delivery (CI/CD) environments.
The tests have all passed and it'’s time to put the code in production, so let’s move on to the Anypoint Management Center, which allows you to:
Deploy, manage, and monitor APIs and integrations in the cloud or on-premises.
Provision access to individuals or across entire teams with single sign-on technologies such as OAuth and SAML.
Manage proxy, control versions, apply prebuilt or custom policies, and set alerts.
Track key metrics like API usage, transactions by region, and performance with prebuilt or custom dashboards.
Identify issues, map dependencies, monitor diagnostics, and manage logs in one unified interface.
Engage: Contribute Your Work for Reuse
Our journey ends in the same place it began: the Anypoint Exchange. Here, you may store connectors, templates, examples, API definitions, even API fragments in a privately shared space, so others in your team can take advantage of the work you’ve done to avoid redundancy and duplication.
Example of a real world use case fits into 3 layer of mule APIs
Why Design an API Spec First
The best way to get started with your integration is to write an API specification. API specifications explain API behaviors, fundamental design philosophy, and supported data types. Taking the time upfront can pay off big time later down the line.
It serves as documentation for reuse by future applications via the Anypoint Exchange.
Stakeholders/consumers of the APIs can perform acceptance tests before the app is ever built.
It can be used to prepopulate your implementation with artifacts and metadata to reduce development time.
What Is an API Specification?
An API specification is a contract that is easily digestible by both humans and computer systems. It’s digestible because it combines both API documentation (think READMEs) and API definitions (like WSDL files). This design simplifies understanding of how to interact with the implementation, which increases adoption and speeds up project completion. So let’s start thinking about our API specification in the language you use: RESTful API Modeling Language (RAML).
Create an API Spec
Create an API Spec
Creating an API Spec in Design Center
Let's start by going into Design Center in Anypoint Platform. The Design Center is your cloud-based environment for building API specifications and Mule applications.
Page updated
Report abuse