Traditional applications are becoming a monolithic concept.
That may sound like a bold statement, but talk to any experienced developer, and they will tell you of the toils and troubles involved in managing a large, homogeneous application.
With front-ends so intimate to the core application that they need to be redesigned with every update, back-ends that hide everything in magic-spewing black boxes, all of it webbed and woven together so tightly that only the most experienced developers can make sense of it, the challenges are real, and universally reviled.
Monolith, your days are numbered.
The concept of the Application Programming Interface has been around for a long while. An API encapsulates a set of functions, say interacting with a database remotely or talking to an image-modifying COM object. This concept has morphed online into things like remote endpoints and web services, and increasingly developers have realized that they can be so much more.
API's aren't a replacement to the traditional MVP-style application, but instead shift the functional part of this model to a more abstracted, easily managed and flexible framework.
API-led development suggests that instead of building an intricately wired-together application that can only talk to itself, all core functionality is moved into a centralized endpoint so that any user-facing application can speak to it in a standardized way. It doesn't matter if it's a web page or mobile application, smartwatch or cybernetic implant, as long as the request is formatted correctly and has the proper permissions, the API will respond.
API's aren't a replacement to the traditional MVP-style application, but instead shift the functional part of this model to a more abstracted, easily managed and flexible framework. API-led development seeks to address not only the known unknowns (our product will evolve–we just don't know how yet, we will be integrating third-party solutions but we don't know which ones, and they will likely change over time) but also the unknown unknowns (such as future interfaces to push our content onto, which don't exist today).
The reasons for adopting an API-led mentality are numerous but can be distilled down to the primary arguments. APIs by their very nature are:
Secure - as API's are accessed remotely by default, their entry point will always exist within the expectation of permissions and validation.
Self-describing - standardized formats like REST and other semantic patterns ensure that a developer will understand the format of any functional requests being made, the response format that information will be returned in, and the functions available to them, all without having to reference detailed documentation.
Reusable - as they exist separate from the front-end "rendering" layer, or view because they are only performing functions and/or returning data, they can be used by any other application without having to be modified or altered for compatibility.
Implementation-independent - you can reference an API from a web page or mobile application and, as long as the request meets the requirements needed, it will respond.
Manageable - because they exist separate from the main, user-facing interface (i.e. the corresponding web page or mobile application), they can be updated and improved independently. Versioning can be used to ensure that older applications reference specific versions of the API.
Mura has offered an accessible API for quite a while (on any standard installation of Mura, version 7.0 or above), via the JSON API. This is a REST-based API whose endpoint returns a JSON-formatted block of data. The Mura JSON API interface can be found under the following URL:
This is the endpoint of the API, and what you see returned will depend upon your permission levels. If you are logged in and have a session available, you will see the full list of available individual object endpoints available. Within Mura these are numerous, but most commonly you would use the "content" endpoint:
Each endpoint will contain not only the information or objects requested, but also a series of related function calls in the form of "links". For instance, if you are within the content endpoint, each returned item will have reference links to any related content, any "kids" (content nodes that exist semantically beneath it), and even the web-rendered version of the content that object represents.
We also have built-in functionality for creating web services within your own customized Mura modules. Web services within Mura can use OAuth for authentication and will act as endpoints to your own application (whether or not you make them RESTful is up to you).
API-led development is a mindset and methodology which will make your projects more robust and reliable, reducing the friction of managing even the largest of them.
Beyond this, Mura also plays very well with external API's. Our webinar, which shares the title of this blog post, is designed to demonstrate how easy it is to integrate an external API into your Mura site by way of SnipCart, an entirely API-based e-commerce solution that will let you add a fully-functional storefront to your site in minutes.
Mura.js encapsulates not only all of the RESTful requests, but includes features like session management, feeds & iterators, a DOM selector and more. It is an abstraction of the core RESTful API, but it is important to note that without the RESTful API, it would have been very much harder to develop and maintain, as all of its functional requests would have vanished into a remote "black box" that would have been at best difficult to use, at worst useless in any other context.
In future blog entries, we will further explore the concept of API-led development as it applies to Mura, both internally (Mura.js-type examples) and externally (integrating 3rd-party APIs). For a quick start, also see our prior blog post, "Super Fast Application Development with Mura 7", as well as our "Mura & Vue.js, A Love Story" webinar.
API-led development is a mindset and methodology which will make your projects more robust and reliable, reducing the friction of managing even the largest of them. We believe strongly in the concept of "Flow", of structuring your development in a way that maximizes your performance while minimizing the distractions and worry of failure that inevitably arise. API-led development is an important step in achieving it.
JSON API Endpoint Reference: docs.getmura.com/v7-1/mura-developers/mura-rendering/json-api/
Mura 7.1 Documentation: docs.getmura.com/v7-1/