Francis Edwards, Integration Analyst at Saint-Gobain and MuleSoft Ambassador, is an experienced MuleSoft developer. He spoke at MuleSoft CONNECT:Now EMEA sharing useful integration tools to help developers get the most out of Anypoint Studio. Below, he provides insight into each tool he recommends as well as demonstrates how he created a Mule app.
In current technology growth, APIs are the standard for building and connecting modern applications. They provide a standardized interface that masks backend complexity and makes it simple for an enterprise to secure, monitor, and manage how the digital assets it shares are used. Below, we’ll take a look at the differences between RESTful and event-driven APIs, an overview of event-driven architecture, and how to implement event-driven capabilities into existing APIs.
This is the second part of a series on “Moving from RESTful to EVENTful.”
As I see more and more companies working to add event-driven, sometimes called “real-time,” APIs to their programs, I am noticing that there are common cases where an event style is favored over others. Using Martin Fowler’s names as a reference point, I’m noticing that event sourcing (ES) and command-query responsibility segregation (CQRS) are the most commonly discussed event styles right now.
Have you ever struggled with opening multiple windows in API Designer as you write your API specification or tediously renamed a symbol by hand in multiple spots of your RAML file? Well, worry no more — API Designer has solved these issues for our developers, making API specification development easier than ever. Introducing API Designer multi-tabbing and rename symbol capabilities! Below I’ll dive into what improvements we’ve made to these features:
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,
Every day, businesses are working toward becoming a ‘digital’ enterprise — but what does it mean to become digital?
Digital design is far more than simply putting your business online; it is changing the people, process, and technology operations of an organization. Thus the term ‘digital transformation’ was coined to show that this is a change in company strategy and not just a simple project. Organizations completely transform the way they operate.
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
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.
