Well defined APIs are an integral part of a headless commerce service because this is how it interacts with the outside world, including traditional and digital touchpoints as well as front-end applications. Well defined API help developers to achieve superior technical agility through:
- Improved Flexibility. Ability to select the most appropriate front-end technology or framework to solve a particular business problem.
- Simplified development. Unified logic across touchpoints to eliminate channel siloes and duplication of development work.
- Accelerated Speed-to-market. Reduced time required to learn the APIs, implement new touchpoints and extend the APIs capabilities.
In this blog post, we will discuss what the API requirements and how a well-designed API can enable superior technical agility for the business.
Questions to ask:
Not all APIs are created equal, as they rely on different architectural styles, frameworks, and technologies. First, we need to understand what helps an API to deliver technical agility by going through the most critical questions to be asked:
- How closely does the API follow industry best practices and standards? This is important because it reduces the learning curve, makes it easier to find the right skills, and ensures the openness of the commerce service. One of the essential criteria for adherence to best practices is the Richardson Maturity model. It scales from 0 to 3, and the more mature REST API is, the higher the score.
- How does the API handles error? Is generic code returned, or does it go beyond that? Proper error handling makes it easier for developers to use the API in their day-to-day work.
- How was the API created? Was it purpose-built from the ground up for headless commerce, or has it been added to a traditional full-stack digital commerce platform? Any vendor can say they’re headless, they have an API, but in many full-stack solutions, the API is an afterthought from the traditional full-stack store and, as such, will not be a feature-complete compared to the store. It may work well for the initial channels which it was put in for, but when stressed with complex purchasing rules could likely fall due to this incompleteness.
- What is the API Architectural Design? Is a foundational pattern or design of the API allows it to be future-proof, or will it cause problems in two years when you will bring on some complex workflows and use cases? While one can’t envision everything, if something looks hacky today, it’s only going to get worse when pressed into real-world use cases.
Elastic Path APIs
We have discussed what questions you need to ask to understand whether the commerce service has the right APIs. Now we will address how Elastic Patch Commerce Cloud answers those questions:
- Elastic Path Commerce Cloud scores on the Richardson Maturity Model on a solid Level 2. We follow industry standards using the verbs GET (read), POST (create), PUT (update), Delete (delete) within our API. We don’t use PATCH as is outlined in the industry, but where the grey area I mentioned comes in. We chose to keep updates to the PUT as a way of keeping it simple. Our PUT’s, however, do allow partial updates like what the PATCH does. If you look at any endpoint in our API, such as through our Postman collection, you’ll see a very clean specification, want to create a catalog item, POST it. Want to change that item, just send the altered items as PUT. No need to specify what you are doing, the REST verb does that for you.
- Elastic Path Commerce Cloud also returns the correct error codes. If you successfully create an object, you get a 201 CREATED. If you can’t find an object, you get a 404, if an object already exists a 409 Conflict. This makes error handling by the front-end application much more comfortable as it then takes the correct action compared to every error just being a 400.
- With Elastic Path Commerce Cloud, the API was created from the ground up to be a headless commerce API. It means that every single function exists in the API, we don’t end up with something in the UI or dashboard which can’t be done through an API call. This ensures that our customers can use and consume the API in any way they want to. This could be with their administration UI or hooking into another existing portal or enterprise system as an input to Elastic Path Commerce Cloud.
- As before with the API design, the Elastic Path Commerce Cloud architecture is a modern design with commerce in mind. This helps to ensure future unknown use cases can still be solved as the product evolves. Unlike some of our competitors where their underlaying architecture is limited to their API and forcing design choice, the Elastic Path Commerce Cloud design is complementary to commerce to ensure that what a customer gets today will still work years from now.
Elastic Path also provides developers with various tools to accelerate development and reduce the learning curve.
This collection is supported by Elastic Path Commerce Cloud environment variables and should be used when you want to do a deeper dive into the API or use alongside development. The variables are meant to make things easier but require some setup. You can find the postman collection here.
Elastic Path Commerce Cloud has a demo store based on Gatsby open-source framework. It is based on React helps your developers build blazing-fast websites and apps. Gatsby is a PWA (Progressive Web App) generator designed to support the latest web technology and large-scale high-performance web sites. It is excellent was to see Elastic Path Commerce Cloud APIs in action.
You can find the source code on the GitHub and the store itself here.
Embedded Commerce works alongside your existing websites and blogs, allowing your customers to shop and pay for items without ever leaving the page. It is quick and easy to set up and provides all the necessary capabilities to deliver superior experiences, including persistent shopping carts, custom cart items, and the ability to save a cart for later checkout. It demonstrates how quickly you can connect your existing front-end to Elastic Path Commerce Cloud APIs.
You can find the source code on the GitHub.
Learn more about how Elastic Path Commerce Cloud leverages APIs as a part of Composable Commerce to enable superior technical agility.