You may well have heard of APIs and, after thinking \”oh well it\’s just something technical again, I don\’t really have to know anything about it\” then wondered, in the back of your mind, \”actually what are they and should I know more about them?\”

The answer for anyone who runs a business is almost certainly yes as they can allow you to do things that you thought were not possible or too expensive.

They are not a panacea and as yet many of them are too \’clunky\’ or inward looking, but like all things in the tech area more openess and functionality is likely to come over the next few years.

So, what is an API?

API stands for application programming interface or something that allows program A to communicate with program B including specifications for how to do something, how data is structured and classed and what variables to use.

Er, so what?

Well one of my favourite descriptions of an API is this one from Katy Levinson:

\”This is an API [Image of child\’s box with circle, square and triangle openings].

This API takes circles, triangles, and squares and lets them into the box. It forces the user or client program to organize the inputs going into the box to the designer\’s liking, presumably so they\’re easier to work with.

The magic elves living in the box, ensure that this API can also serve data out by having the elves push the shapes back out of the holes. This is useful to the user/client program because now the outputs come out in the way users expect them to i.e. squares come out of the square hole and not circles etc. and will always do that.

Because of this APIs have many advantages. You generally don\’t want to have a closed lid on your box nor an open box. But without some form of control people could begin pushing star blocks or perhaps live sharks into the box and this would be disagreeable to your magic elves. Conversely, perhaps one day you want to rearrange the insides of your box. This would be disagreeable to your users who would have to re-learn how to interface with your box. With this special lid on here, your users can not put anything in the box your elves do not like, and how you arrange the org chart of your magic elves inside remains inconsequential to your users.

In this way, an API forces structured data-based (or, in this example, block-based) exchanges between what the designer made and the outside world which wants to use it.\”

Beginning to get the idea?

As an API is a way for your website to talk to another website and lets you mix information and media from other services into your own site or application.

That means that, in theory, anybody can create applications for you site. They can then mix, match and mash these up into different services and new applications that are beyond the original idea. APIs can be ‘language independent’ so no matter what programming language a developer is using, they can still connect through the API.

This is how Facebook, Twitter and many others have grown so fast.

There are naturally drawbacks to APIs as Andy Wibbels has pointed out:

– you are dependent on the API service provider. So if Twitter disappeared all those applications wouldn’t be able to connect through the API and would cease to be useful

– you’ve got, potentially, many developers who might make money from your service, and although you can charge for access to the API then you might lose your developer community

– you have to have the staff and data centers to handle your normal customers along with those coming in via the API and those customers may not be your core audience

But the idea has a lot of appeal right? Because with solid APIs you can do things that you thought were not possible or too expensive.

At the time of writing progammableweb has 6,201 APIs listed and 6,663 mashups.

How can you use an API?

There are 3 types of API:

– Private APIs: integration points between internal systems and processes such as databases, warehouse management systems, inventory management, accounting, and POS systems.

– Partner APIs: integration points between your organization and business partners such as procurement and credit card payment processing. These APIs typically follow open standards for integration.

– Public APIs: exposing information and functionality, with limited restriction, to outside business partners, application developers and mobile devices to enrich functionality and processes while increasing reach and driving revenue.

There are 2 routes to consider.

– Use others APIs

– Build your own API

Using others APIs

This, clearly, depends on the business you are in. Let\’s say you are a second hand book dealer. How could you leverage things in such a way as to expand your channels but maintain relatively simple control?

– First, build your own ecommerce site.

– Second, ensure you have the inventory management, pricing and distribution set up really well inside the application or using private and partner APIs.

– Third, look around and see where else you could sell, for example:

ebay

Amazon

ABE Books

– Fourth, sign up, use the APIs and monitor and improve performance

Building your own API

This requires somewhat more thought as you are not \”following another\’s rules\” but creating your own interface(s) directly into your ecommerce or other application.

If you are a retailer that might mean a smartphone app or a point of sale app that feeds into other mobile apps and affliate sites.

Credera and APIGEE have suggested the following approach to building an API:

Step 1 – Define the API

Determine what data and processes will be exposed to the outside world. Think in terms of nouns and verbs that apply to your business. Words like

“Customer”, “Product”, “Catalog”, “Price”, and “Order” are all nouns that may have explicit meaning to your business. Verbs like “retrieve”, “update”, “submit”, “calculate”, and “track”, are all verbs that may describe operations that will be performed on those nouns.

Step 2 – Map the API to Legacy Systems

The next step to realizing a functional API is to map the data elements and functionality of the new API to their location in existing systems. Any holes that are discovered will have to be filled.

Step 3 – Implement the Integration Layer

With a goal to extend existing legacy data and processes to the public, this is a system integration effort rather than a new application development effort.

Regardless of the platform or language you can consume internal APIs to communicate with legacy systems. You’re not really building new systems as much as you are creating an integration layer, “the cartilage”, between the public and your internal systems.

Step 4 – Implement Security

Remember that when you are exposing data and functionality to the general public, security must be a priority. This is especially true if the data you are exposing is sensitive, or if you are allowing people more than read only functionality on the data (e.g. changing account information, placing an order, etc.)

Step 5 – Scale to Fit

One thing to be aware of when opening your data and processes up to the public is transaction volume. You don’t want a sudden surge in the use of your API to bring down your backend systems and processes.

Step 6 – Document the API

Documentation is a very important step in this process. Your APIs will be used by third party business partners, system integrators, mobile application developers, etc. Typically, a well designed API is relatively self explanatory, especially if it is defned by an XML schema and/or WSDL. However, additional documentation within the XML schema is usually very helpful, as is a WIKI or site for online documentation.

Of course, once you have an API you have to market it. Shaival Shah has suggested the need to:

– Develop market awareness for your service and availability of your API

– Absolutely nail 3 partner use cases that has strong re-use across the market

– Determine success metrics, analytics (proof that your API yields value to 3rd Party) to preserve future monetization options

Anyway – hope all this was useful and may give you a few ideas.

Richard Hill is a director of E-CRM Solutions – a Bath based web design and internet marketing agency and has spent many years in senior direct and interactive marketing roles. E-CRM helps you to grow by getting you more customers.

Richard Hill is a director of E-CRM Solutions and has spent many years in senior direct and interactive marketing roles. E-CRM helps you to grow by getting you more customers that stay with you longer. http://www.e-crm.co.uk/newsletters/2012/using-apis-to-leverage-business-growth.html

Author Bio: Richard Hill is a director of E-CRM Solutions – a Bath based web design and internet marketing agency and has spent many years in senior direct and interactive marketing roles. E-CRM helps you to grow by getting you more customers.

Category: Internet
Keywords: api,growth,business,marketing,internet marketing