This is a guest blog from a member of the MuleSoft community. Brad Cooper is a senior developer with more than 20 years professional experience in a variety of tools and languages, including Anypoint Platform. He holds numerous MuleSoft certifications, – including MuleSoft Certified Developer: Integration Professional – and hopes to add MuleSoft Certified Architect: Solution Design Specialist in the near future.
If you were existing anywhere but under a rock for the last few weeks, then you were probably subjected to a gauntlet of GDPR notifications from the websites that you frequent, including ProgrammableWeb. They may not have even mentioned GDPR or the General Data Protection Regulation. But the sudden onslaught of these messages while visiting those sites, or via email, or both was unquestionably due to the mad rush by website operators (your’s truly included) to meet the May 25 deadline for complying with the sweeping privacy regulation that was established by the European Commission (EC).
In a previous life, I worked primarily with the operational side of the IT business, which is concerned with monitoring and operational alerting. The requirements we implemented were variations on a theme that typically started with the business asking IT to provide an SLA for “availability” of a service as well as an SLA for the responsiveness of a service. On the surface, these requirements were clean and simple, but in practical terms, things got murky very quickly.
Last fall we wrote an article that examined which APIs draw the most interest from developers. In that article we relied upon the API tracking functionality that each profile has as the metric for determining which APIs are the most popular. As many users of ProgrammableWeb know, reader’s can track any asset on ProgrammableWeb.com (APIs, SDKs, even search results) in the same way they can track stocks on a financial site. If anything new happens to that asset (if it gets updated,
Looking across the entire landscape of software that businesses buy, it is clear that APIs are becoming a competitive differentiator for companies of all sizes.
What is the difference between web APIs and web services? Let’s start off with an analogy: all tigers are cats but not all cats are tigers. In a similar way, all web services are APIs, but not all APIs are web services. Web APIs and web services are often confused with each other; however, web APIs are an evolution of web services. Both facilitate information transfer, but web APIs are more dynamic than web services are.
There are various types of APIs, the most popular of which is Web API––otherwise known as a Web Service. A Web API provides an interface for Web applications, or applications that need to connect to each other via the Internet to communicate. Web APIs have exploded exponentially, reaching over 17,000 in 2017. There are four popular subcategories of Web APIs, including SOAP, XML-RPC, JSON-RPC, and REST.
It’s the classic question: should IT spend its time maintaining legacy investments or addressing legacy system challenges and creating new projects?
In a recent survey, 90% of IT decision makers say legacy system challenges are holding their organizations back from using digital technologies to innovate or make improve IT efficiency, and over a third believe that legacy systems are a barrier to completing IT projects.
In our technology-driven world, organisations cannot afford to stand still. They need to deliver software at high velocity without sacrificing stability, which is why DevOps has become such a popular approach.
As the name suggests, DevOps is an attempt to combine software development and IT operations in order to effectively get the best of both worlds: the rapid iteration favoured by the former and the stability, reliability and security favoured by the latter.
Before we get started with this blog, if you haven’t checked out Part 1 of this Dev Guide series, make sure you work through that first, where we went through developing a resilient, governable, and flexible API layer on top of your source systems—what we call system APIs.
