API Design

 With API First approach gaining more traction it is very important to emphasise on good API Design. Designing a good API is more of art and iterative process.It is critical to put the Users first and spend a lot of time on refining the APIs.

A few years back APIs were considered to be just a software interface to connect disparate system to achieve a business capability. This was the bare minimum expectation but over the years this has increased to leaps and bound. 

Based on API 360 model, an API design should consider the following

• Usefulness - Does it address any relevant Business problem.
•  Engagement - Is the API easy to adopt and how good is the Developer Experience
•  Evolvability - Can it address the future requirement like support more users, different regions, etc
•  Security - Is it secure and manageable

The key considerations the designer has to keep in mind when designing an API are

• Who are the users of the APIs

Are the intended Clients internal or external to the organisation. Based on AWS API Mandate, an organisation should not build different set of APIs to cater for internal and external usage. Internal APIs should be build with the consideration that it should be able to support external traffic with few controls in place.

• What is the business problem the API is supposed to address

Identify the API type based on the capability it is expected to support

API types falls into 3 main categories

• System API -  API to support simple CRUD operation
• Process API - API to support interaction among different system, eg Generation of Consolidated Bank Statement
• Experience API - Typically custom made for external users

• Does the API handle any sensitive data

Proper encryption and encoding should be considered when handling sensitive data.

• Is it a global or region specific API

If the business process is region specific then building a single global API to handle all regions requirement could be an overkill and it is better to build region specific API and weave them together as Global API. For eg introduce an HTTP header to specify the market or region and the Global API would just do the routing to specific region.

A few best practices to consider when designing an API

1. Avoid jargons in API URL and field names
2. Use HTTP Methods and Resource to define the URL
3. API fields must be least restrictive
4. The API Response must reflect the resource mutations
5. Use Enums instead of Boolean
6. Timestamp field naming should  be <<verb>>ed_at format
7. Currency should be used to represent amount fields
8. Consistent way to search and list results
9. Use Nested Object instead of flat structure
10. Error Codes must be consistent across end point
11. Use consistent Authentication mechanism
12. Consider the throttling and rate limiting parameter
13. Leave place holders for Sunset headers
14. Strive to make any changes to API as backward compatible

Dockerizing Spring Boot App using Maven

This post details the steps required to dockerize an existing Spring Boot App

1. Create a Spring Boot App
2. Run  and verify the working of the App
3. Include the following  build plugin details  in  POM file to create the docker image

JSON API

JSON API is a specification that defines the standards for exposing and consuming API from Server and Client perspective.This brings in a common convention that provides a mutual understanding of interaction patterns between the client and server.JSON API formulates 3Rs - Resources,Relationship and Repository

There are a number of open source library available in different languages to support  JSON API . In Java, the following are a few

• katharsis
• crnk
• Elide

Adhering to JSON API increases the efficiency and performance of API consumption model by reducing the number of requests and amount of data transmitted .

JAXB UnmarshalException when converting Payload in Camel

Camel provides camel-jaxb jar  for converting XML to POJO data and vice versa using JAXB data format.

The samples provided in the documentation states that the contextPath should be set to the Java Package of the POJO class for the marshaling and unmarshaling purposes.

But when trying to set the contextPath to a required class package  it throws the exception “javax.xml.bind.UnmarshalException: unexpected element Expected elements are (none)”

This is raised because meta-data information is missing and the registryFormat element is not found in the context. This can be fixed by creating the Context with the Object Factory class and using this reference to unmarshal the data. 

JAXBContext jaxbContext = JAXBContext

                           .newInstance(new Class[] { com.test.ObjectFactory.class });

              DataFormat registryFormat = new JaxbDataFormat(jaxbContext);

              from("file:in?noop=true").convertBodyTo(org.w3c.dom.Document.class)

                           .unmarshal(registryFormat)

                           .log("The message after conversion" + "${body}");      

Unresolved constraint error when installing bundles in Fuse

When installing a bundle in Fuse, it quite common  to encounter the Unresolved constraint error: missing requirement: osgi.wiring.package error.

This error is thrown when the packages imported using Felix plugin are in conflict or if the dependent bundles are not installed. 

The article in this link provides a detailed explanation on the cause and fixes for this error 

But for those looking for quick fix ,the following steps would be handy.

• Use osgi:headers <> to list the manifest details of the bundle.
• In the manifest details,check for packages are marked in Red in Import-Package Listing. These are the  candidates which potentially cause this error.
• Verify if the bundle corresponding to the erroneous package is installed and started 

These  steps should help to resolve most of the unresolved constraint exception when installing a bundle.

IllegalArgumentException when invoking a webservice from a Camel Route

If a service exposes more than one operation then the operation name and namespace should be set in the header before invoking the call from the Route.

The IllegalArgumentException or BindingOperationInfo Exception is thrown when the framework is not able to find the matching operation to invoke.To fix this ,verify the operation name and namespace from the service class defined in the CXF EndPoint Bean.If the operation name or namespace is different,the binding would fail and IllegalArgumentException would be thrown.To fix this error,ensure that  the operation name and namespace match with the details given the SEI class.

  

<route>

     <from uri="timer:foo?period=5000" />

     <setHeader headerName="operationName">

            <constant>generateText</constant>

    </setHeader>

    <setHeader headerName="operationNamespace">

       <constant>http://com.test/generateservice</constant>

   </setHeader>             

  <to uri="cxf:bean:generateService" />

 <log message="The message contains ${body}" />

</route>

In-Memory Components

Camel provides in-memory components like  Direct, Direct VM,SEDA and VM .These components route  messages without using external broker.They should be used when performance or speed takes precedence over reliability requirements.

Direct/Direct VM :

The Direct component allows to make direct synchronous call between a producer and a consumer. This is the simplest component as it requires no additional configuration. It is mainly used to link routes within a Camel Context  and  to expose a route as a synchronous service.

Direct VM is similar to Direct ,only difference is that it supports communication across multiple Camel Context instances within the same JVM.

SEDA :

The SEDA component  is used for asynchronous messaging and is considered as low overhead replacement for JMS .SEDA allows messaging  within a single  Camel Context. It supports concurrent users  in which the configured end points will be triggered and run in separate thread.

VM is similar to SEDA except that it supports communication across multiple Camel Context instances within the same JVM.

Component	Pros	Cons
Direct/Direct VM	Simple to use Allows to reuse route Minimal Overhead	Used only when Producer and Consumer are up at the same time, this may not be viable for all use cases. Works on Single thread only
SEDA /VM	Faster than JMS as it is in memory Supports concurrent users	Message Persistence not supported so there is a risk of losing message if event of   crash. Transactions are not supported as each call is invoked  on a different thread.