When I was interviewed for my role at MuleSoft a few months ago, I was asked if it was possible to have more than one System API layer. I froze — and it’s possible this question has crossed your mind as well.
After the interview, I sketched out some use cases to figure out the answer to this question. It did not take long for me to understand that API-led connectivity is not strictly restricted to three layers — System API,
For close to twenty years, the “common standard” of APIs on the web has been summed up in one word: “RESTful.” Designers, developers, and software architects have promoted, debated, and derided the notion of RESTful APIs in successive waves over the years with all sorts of pundits declaring REST “dead” and offering some other current practice as “the new REST” or, even better, “the REST killer.” Probably my favorite rejoinder in this space is Matt McLarty’s “
This is the first article in a two-part series focused on API documentation and discoverability
The API developer experience
APIs are no longer treated as solely an integration technology but are also viewed as software products that can empower an organization with modern digital business channels and additional revenue opportunities. The most forward-looking and savvy development teams are building reusable APIs that can increase the development speed across an entire organization,
IT is under continuous pressure to keep systems available and maximize the uptime to ensure users have an unmatched experience. With the growing number of user experiences (such as 24/7 services, mobile, and eCommerce), every moment of downtime translates to loss in revenue or a missed opportunity.
To define a stable and scalable system, one must analyze and focus on attributes like system availability, desired system uptime and acceptable downtime (outage),
When surfacing data from systems of record, one of the concerns designers and developers need to address is the potential of retrieving an enormous number of results in a single load session. This requires significant processing power on both the client and server sides and network traffic, and can degrade the overall data consumption and experience.
There are different approaches to address this concern, but one of the most widely used is the concept of pagination.
The reality of supporting production event-driven architecture at any reasonable scale is that it can be challenging, especially when dealing with bad events and unhappy paths, both of which affect business operations and the customer experience. Architects and developers often focus on delivering the minimum viable product (MVP) to show business value early and validate the approach taken. While focusing on the MVP can be valuable in establishing IT agility — the requirements are targeted at normal operation,
One of the key tasks of supporting a vital API program for your company is dealing with change over time. In previous articles, I’ve talked about the importance of managing the entire API lifecycle and how to recognize important milestones in the life of an API. These milestones often signal that a change in the way the API is treated, measured, and managed needs to change.
In this episode, Mike and Matt are joined by special guest Stephen Fishman, Regional Vice President of Customer Success Architecture at MuleSoft and longtime API product expert. Stephen shares insights on product-oriented approaches to API design, development, and lifecycle management. Topics range from API discoverability to launch strategies to a relentless focus on API consumers. Have a listen here:
A close friend and mentor of mine (Patrick Quattlebaum of Harmonic Design) once said “All systems have a design. The question is ‘is the design intentional or random?’” What he meant is that the design of interfaces created inside an enterprise (graphical or not) communicate how much that organization values the time and effort of their users. In addition to functional communication, these interfaces also communicate your enterprise’s commitment to low-friction experiences.
Unit tests are executed at different stages during the development life cycle. As mentioned in the first blog post of this series, MUnit for Java Programmers: Introduction, unit tests play an essential role in the implementation, maintenance, and evolutionary stages of a project’s life cycle. Tests can be executed during each of these stages and the results are collected and analyzed. Should the application pass the series of tests it will continue on its journey through the project’s lifecycle.
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.