364
EXPLORE what we know and do
EXPLORE what we know and do

Close

Competence areas

Contact me

Valdation:
* First Name:
* Last Name:
Company:
Phone number:
* Email:
Country:
* Message:
Successfully sent!
Could not send the mail, try again later!
COFFEE OR TEA? Drop by for a cup.

Blog January 31, 2017

Enfo – API’s for you?

We have worked, and sometimes struggled, over these past years building integration platforms and utilizing SOA (Service Oriented Architecture). While the idea behind SOA was (and still is) great, we see that a lot of our customers are not reaping the full benefits and paybacks that SOA promised to deliver.

We expected much quicker, leaner connections and re-usability along with a solid control of our messaging and platforms but many never really got there… Some did, but those were just a few… What we failed to see was that a lot of the software/systems we needed to communicate with was not ready for any type of synchronous communications and often required a lot of modifications and/or configuration to provide an endpoint suitable for the SOA platform and with that the “quicker, leaner connections” went out the window.

Same for re-usability, we were supposed to be able to reuse most, if not all, of what we built in SOA. Again, various messaging formats and protocols, lacking standards and cumbersome interfaces stood in our way to be able to re-use much of what we built. We still could re-use some and use much as “templates” building new message flows so all was not a loss but we came nowhere near what we had thought or expected when first jumping on the SOA train…

As for “solid control” SOA delivered a better viewpoint of messaging and routing for most companies but the SOA software itself lacked the capabilities for monitoring and analytics and there was no standard to extract and use information form the platform. We did gain better error handling and monitoring and in most cases transactional messaging though, which was a great benefit to many. The lack of synchronous protocols, e.g. file shares, JMS, sftp, or “one-way” connectors, made detecting errors and reporting errors back much harder. This is especially true for external (B2B, business-to-business) communication where you could receive an invalid message and the error was not detected until inside the SOA platform of the receiver and the receiver have to find the error and communicate to the sender that they did something wrong.

So, did we do anything wrong or was SOA simply a bad idea from start?

Looking back we did well as an industry and SOA was a good idea but what we failed to realize is the investment that a “full” SOA implementation requires from the whole company’s IT. The SOA software available at the time wasn’t always up for the task of delivering the more “fine-grain” functions required and utilizing asynchronous protocols of course made things worse.

Looking at transformation of message types and routing, though, SOA did a very good job and helped a lot of our customers deal with the “spaghetti” of point-to-point integrations done before SOA and Enterprise Service Bus (ESB) technology came along and by that providing more order and an overview of the system wide communications. SOA focused mostly on how to collect a message, transform it and deliver it to a recipient in a way the receiver wanted it and a lot of the time was spent on the endpoints, fetching and delivering messages, and not so much on the message, the data, itself. The technology required to be able to connect and deliver data was key selling points for SOA software and the more adaptors/connectors and ready-made transformation you could offer the better. This knowledge and technology used to connect various systems in your enterprise is something that we now can re-use and utilize moving forward into a world of API’s!

Looking at the key differences in the software solutions between SOA and API is that API software has been forged based on standards, offering few but solid technologies to exchange data, where the key is “data” and synchronous communication. While SOA most often focused on connections and messages API focuses on the data. This means that we are no longer looking to connecting systems but instead on offering data to subscribers. This also means that we need to get to know our data and what we can offer (publish) to other interested parties, both internally and externally.

The first thing we should look at is thus Master Data Management (MDM) to document and understand our master data and what, and how, to expose it. In many cases the SOA platform will play a crucial role in the collection of data as many backend/legacy systems can’t publish its data in an “API fashion” and need help to do that. Having the setup in place with the already working adaptors/connectors to these systems will make the transition into the API world so much easier and we will gain even more reusability from our SOA platform.

As stated the first thing we should do when starting out with an API platform is to review what we need/want to publish. Often this “need” stems from requirements from an internal project or external parties that wants an API connection. How we should publish the data is much easier from a technology standpoint as API’s offers a standard to use, we simply have no choice in how to do it technically. There is one thing to note though, what do we include in the term “API”?

Most would claim that API’s today is based upon a REST interface utilizing HTTP as protocol and JSON as a message standard. We all know what HTTP is today, it’s proven and extremely stable in today’s networks, both internally and over the Internet so there’s no question that it is the correct choice. REST means we are using “verbs” for the action to take and URI’s for routing and/or identifying.

-    REST verbs are the HTTP METHOD used, for example GET, POST, PUT, DELETE, etc. which are quite self-explanatory, except maybe for “POST” and “PUT” which really means “CREATE” respectively “UPDATE”. We can also create our own verbs in REST but that’d be mostly recommended for internal use only.

-    URI is the path in the URL, e.g. http://myserver.com/v1/order/ has the URI of “/v1/order/” which means that we are using version 1 of the interface and along with the verb POST we are creating an “order”. Using the URI of “/v1/order/{order number}” with the verb “GET” would instead fetch an existing order.

-    JSON is the JavaScript Object Notification standard, really a key-value pair solution very similar to XML but more streamlined and smaller.

The older standard for WebService´s (WS) is quite similar in handling of routing using URI’s but not verbs. Instead mostly using “ports” or named functions which gives a lot more interfaces to keep track of. Some API platforms can handle both REST based JSON API’s and SOAP based WebService’s so if you have a lot of WebService’s or demands for SOAP/WS then look at a API solution that can offer both functions in the same solution. We at Enfo will gladly help you with any questions you might have!

When it comes to the usage of the API’s both WebService’s and REST based API’s offer a “self-documenting” standard in WSDL (WebService Description Language) for WebService’s and OpenAPI Specification (Swagger 2.0) for REST based API’s. There are several standards for REST based API’s; RAML, API Blueprint, WADL, Slate, etc. but the fasted growing and most adopted is Swagger so that would be the safest bet. Obviously we will gain a lot by a standardized documentation which can also be imported into the actual API platforms creating the API’s automagically!

Basing everything on strict standards and standard descriptions of the services is one of the major benefits to API’s (and of course WebService’s)!

We all use the same standards, all over the world, so no more transforming between American ANSI X12 EDI to the European EDIFACT is needed and we don’t need different protocols, e.g. OFTP for the car industry. We’ll all use one and the same standard! (FINALLY!)

Using synchronous communication means that we always can report back the status of the message in a response message or a response status as a HTTP return code. This gives us the benefit that we can validate (and transform if needed) on the fly and if something goes wrong we can reject the message. This will give the sending party an error so they can deal with the issue and we won’t have to spend our time and resources fixing their issues.

These are just the major technical advantages to API’s, then we also have the benefit of being able to build more streamlined interfaces and to better keep track of our data. The main gola should be to only store data once, no more replications or duplicate data anywhere. If a web portal for customer services needs a customer’s address it will query the “customer API” for the address only and the API platform makes the decision on where to get the address from. When we build a new mobile app for the customers to use, we simply re-use the same “customer API” but deliver the data in “mobile” format instead which is something the API platform handles for us.

Handling all data as “building blocks” (think Lego) we can quickly and easily build hybrid API’s to deliver any needed data as most API platforms utilize a graphical user interface (GUI) for quickly pulling smaller API’s into bigger ones.

In (most) API platforms you’ll also gain visibility through analytics and statistics as well as “plans” where you can decide how much your API’s can be utilized. Perhaps you want to charge for heavy usage and only offer a limited amount of requests for free or let internal systems utilize the API with an unlimited plan but external users only a few per second, per day or whatever you like.

Authentication and authorization are also something that you’ll gain from the API platform. While SOA mostly identified systems, API’s can identify the actual client, being a system, mobile or a person.

Some API platforms also gives you a “Portal”, normally referred to as a self-service portal where your users/clients can handle their own credentials (after being allowed access of course), download Swagger documentations and review different versions available and get help through discussion boards/forums (if you opt to enable the functions).

API platforms today are built to service both the developers and the managers of the API’s, truly making it a one-stop-shop for all your integration needs (and demands)!

If you think you can benefit from the world of API’s, please don’t hesitate to contact us!

Anders Wasén, IBM Champion, Enfo Integration, anders.wasen@enfo.se