GraphQL offers a new style of API design intended to provide API consumers with unified access to back-end data and services. In spite of this seemingly universal aim, GraphQL has created a schism in the API community between those who believe it is superior to state of the industry RESTful API design and those who believe it is naively re-introducing solved API design problems. This blog examines GraphQL,
API creation and adoption are having a moment. As of January 2018, there are nearly 19,000 public APIs in ProgrammableWeb’s API directory. According to recent research, 94% of companies say they either have or are developing an API strategy. APIs are seen as an enterprise necessity.
This is the question that many of us are faced with when starting with APIs, and quite invariably, there would be either of two broad scenarios that we generally find ourselves in. We are either starting green field under the clear blue sky with every little thing to elicit, introspect, and design; or else we are in a continuum, trying to understand the current system,
Picking up from the second part of this series, this blog post will wrap up building an end-to-end API solution. For the first post, you abstracted source systems with APIs to add flexibility, ease of consumption, and increase adoption and integration possibilities.
Here at MuleSoft, we talk a lot about how API-led connectivity can speed up your development cycles, and I’m here to guide you through how to do it. The API-led approach is a natural evolution from developing libraries, writing digestible markdown files, and sharing them on GitHub.
Update 10/23/2017 from the training team: In the light of your feedback on how much you love this certification, we’ve elected to not retire this certification and, instead, release the MCD – API Design Associate (RAML 1.0) as a non-proctored certification exam. You’ll be able to take it as a stand-alone exam, or using the voucher that comes with the Anypoint Platform: API Design course. Thanks for letting us hear from you!
This blog post is a guest contribution from Jonas Borjesson, Tech Lead SIP at Twilio Inc.
Harnessing the power of APIs is the key to competing in the new era of software. APIs provide the agility developers and businesses need to iterate and innovate quickly, and they’re everywhere. Businesses all over the world are looking to roll out or even acquire APIs, but if they don’t succeed at winning over developers,
In part 1 of this post, we have established the overall value proposition of defining reusable KPIs in an attempt to assess and drive the concept of reuse within your API platform. Once the capability to establish and monitor both abstract baselines and progress against them have been established within an enterprise, the next step is to determine what metrics are worth tracking, where they break down, and how they relate to each other.
A lot of enterprise IT concepts and tools have experienced dramatic change in the last decade. Several long-lived rules of thumb have faded into irrelevance. However, one conceptual holy grail has survived the volatility of the IT transformation toward all things cloud, DevOps, and APIs: reuse. Like historical explorers seeking the Northwest Passage, enterprise IT executives have long sought out ways (e.g. SOA) to drive down the cost of solution development through code reuse.
Over the past few months, I have been working with our Product and Engineering team on Crowd, the latest release of Anypoint Platform. The Crowd release consists of updates to Anypoint Exchange as well as the new Anypoint Designer Center in Anypoint Platform.
MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.