Alex Leung

Magento 2 REST API invocation examples, and why they matter

Blog Post created by Alex Leung Employee on Feb 19, 2016

Magento 2 comes with built-in set of REST APIs:

List of REST APIs by module

plus nicely formatted documentations for each of these API;

Magento REST API documentation (thanks to swagger)


In particular, its authentication API looks very relevant to many customers' headaches: as REST APIs are taking over the world in terms of their massive traffic between mobile apps and their backends, these APIs are becoming a greater and greater burden to the origins. Media customers as well as eCommerce customers invariably seek help from Akamai on how these authentication / authorization requests can be offloaded to our edge.


Let's firstly get Magento 2 installed on say a free tier AWS linux:

Installing Magento 2 on an AWS EC2 Instance Using LEMP Stack



Then, let's take a look at how authentication and subsequent REST API calls would take place:


curl -X POST "" -H "Content-Type:application/json" -d '{"username":"", "password":"IWontTellYou"}'


Akamai can help by caching the authentication response for a few seconds under a unique cache key to offload the origin from having to re-authenticate end-users who have already authenticated.


Akamai can also help by suggesting the token be implemented in an EdgeAuth 2.0 way, so that when the end-user makes subsequent API calls such as those listed below, our Edge servers can perform authentication on behalf of the origin.


With a valid token at hand, let's invoke another API:

curl -X GET "http://media.hi/magento2/index.php/rest/V1/customers/me" -H "Authorization: Bearer akk0vawbxds0no8561gm7i214xu9wtuf"

{"id":2,"group_id":1,"created_at":"2016-02-18 23:57:38","updated_at":"2016-02-18 23:57:38","created_in":"Default Store View","email":"","firstname":"Alex","lastname":"Leung","store_id":1,"website_id":1,"addresses":[],"disable_auto_group_change":0}


The above API looks uncacheable, as the output is highly customized to the specific end-user. Yet, Akamai can still help by recommending API Prioritization cloudlet, for throttling the API from being overloaded, and prioritizing premium user segments.


In contrast to pass a valid token, if I give it an invalid one, what would happen?

curl -X GET "http://media.hi/magento2/index.php/rest/V1/customers/me" -H "Authorization: Bearer invalid_token"

{"message":"Consumer is not authorized to access %resources","parameters":{"resources":"self"}}


So again, if the token is implemented in an Edge Auth 2.0 way, the above API call would found out to be invalid at the Edge, and would never have made its way to the origin.


Magento 2 certainly looks like a handy lab environment for developers to try out interesting ideas of API acceleration, including but not limited to:

- EdgeAuth 2.0 for authentication at the edge

- JWT for authentication at the edge

- API prioritization cloudlet

- adding a HTTPS certificate using Let's Encrypt

- HTTP2 apache / ngix for protocol level acceleration

The author would like to thank Manuel Alvarez for sharing his API acceleration ideas, serving as foundations for this blog post.