Lakmali Erandi Baminiwatta’s blog

REST APIs being exposed over HTTP mainly, there is a great advantage for APIs through HTTP Caching. Why caching is important for REST APIs?  Reduced server load, Low response time Save bandwidth The biggest gain through caching for REST APIs is reduced server load, because the clients can store a cached response for sometime in their local store and access it without hitting the server. So it will result in a low response time to the client making things faster for them. Further, using E-tags (Entity tags), clients have the ability to check with the server whether the response has updated or not. The response body is sent to the client only if the response has changed from what client has cached. Otherwise a 304 Not-Modified response is sent without a response body.  We'll discuss about ETags more later in this post. What to cache?  In your REST API, there can be data that doesn't change more frequently and also data that changes frequently. We can...

Not so long ago, I happened to do a research about HTTP/2 and how it affects performance of web services for my Masters. In this blog post, I am describing the basic details of the HTTP/2 protocol.  HTTP/2 the latest version of Hyper Text Transfer Protocol, is an optimized transport for HTTP semantics. Hence, it supports all the core features of HTTP/1.1 [1] . The aim of HTTP/2 is to be more efficient by addressing limitations of HTTP/1.1 [1] . There are 5 main features of HTTP/2. Multiplexing Header Compression Request prioritization Server push Binary message frames.  Connection establishment in HTTP/2 HTTP/2 also uses the same “http” and “https” URI schemas and same port numbers as HTTP/1.1. Therefore, implementations processing requests for target URIs with“http” and “https” should have a way to discover whether the next hop supports HTTP/2 or not. The determination procedure for HTTP/2 support is different for “http” and “https” URIs [1] . Start...

WSO2 API Manager allows on boarding new users to the API store through a Sign-up page. The default sign-up page has set of mandatory and optional fields for user to provide details. However, there can be cases where one needs to customize the available fields by modifying available ones or/and adding new fields. This can be easily achieved in WSO2 API manager since the fields are loaded dynamically from the user claim attributes. So this post explains how we can customize the default Sign-up page. By default API Store Sign-up looks as below. Note that this blog posts shows how to do this in APIM 2.1.0. Let's say you want to add a new field called 'City' to Store Sign-up page. This post provides step by step instructions on how to achieve this. 1. Start API Manager 2.1.0 and go to Management Console (https://localhost:9443/carbon/) 2. Go to Claims -> Add -> Add Local Claim 3. Enter the below values for the new claim. Claim URI :  http://w...

WSO2 API Manageris a 100% open source API Management solution inluding support for API publishing, lifecycle management, developer portal, access control and analytics. APIs have their own life cycle which can be managed through WSO2 API Publisher while enabling many essential features for API Management, such as, Create new APIs from existing versions Deploy multiple versions in parallel Deprecate versions to remove them from store Retire them to un-deploy from gateway Keeps audit of lifecycle changes Supports customizing lifecycles  The ability to customize API life cycle provides a greater flexibility to achieve various requirements. There are few extension points available for customizing the API Lifecycle. Find more details about those from the product documentation [1].  Adding new lifecycle state Changing the state transition events Changing the state transition execution (In each state transition, we can configure an execution logic to be run) ...

WSO2 products support encrypting passwords which are in configuration files using secure vault. You can find the detailed documentation form here of how to apply secure vault to WSO2 products. This post will provide you the required instructions to apply secure vault to WSO2 APIM 2.0.0. 1. Using the automatic approach to encrypt the passwords given in XML configuration files. Most of the passwords in WSO2 APIM 2.0.0 are in XML configuration files. Therefore you can follow the instructions given in here to encrypt them. 2. Encrypting passwords in jndi.properties file and log4j.properties files. As did in above section, the passwords in XML configurations can be referred in cipher-tool.properties file via Xpaths. Therefore cipher-tool can automatically replace the plain text passwords in XML configuration files. However, passwords in files such as jndi.properties file and log4j.properties filee need to be manually encrypted. Encrypting passwords in jndi.prop...

From WSO2 APIM 1.10.0, we have introduced new feature to define dynamic endpoints through synapse default endpoints support. In this blog article, I am going to show how we can create an API with dynamic endpoints in APIM. Assume that you have a scenario where depending on the request payload, the backend URL of the API differs. For instance, if the value of "operation" element in the payload is "menu", you have to route the request to endpoint1 and else you need to route the request to endpoint2. { "srvNum": "XXXX", "operation": "menu" } In APIM, dynamic endpoints are achieved through mediation extension sequences. For more information about mediation extensions refer this documentation. For dynamic endpoints we have to set the "To" header with the endpoint address through a mediation In-flow sequence. So let's first create the sequence which sets the "To" header based on the payload. Cr...

WSO2 API Manager has integrated Swagger to allow API consumers to explore APIs through a interactive console which is known as 'API Console' This swagger based API Console supports invoking APIs i REST style out of the box. So this post going to show how we can invoke APIs in SOAP style in API console of WSO2 API Manager 1.7.0. For that we need to do few extra configurations. 1. Send SOAPAction and Content-Type header in the request 2. Enable sending SOAPAction header in the CORS configuration First create an API for a SOAP Service. In this example I am using HelloService sample SOAP service of WSO2 Application Server. This HelloService has a operation named greet which accepts a payload as below. <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://www.wso2.org/types"> <soapenv:header> <soapenv:body> <typ:greet> <!--Optional:--> <name>lakma...