Contact with

Our Technical Expert

by submitting this form, you agree to our privacy policy
R
E
Q
U
E
S
T Q
U
O
T
E

Every company starts with a single website or web application, but as a company’s internet presence grows, many different applications and websites are deployed. With a traditional approach of treating each of these applications as a completely separate solution, a number of problems occur: common functionality is implemented inconsistently across applications, maintenance costs are high and time to market for new applications suffers.

By introducing a service API the problems of the traditional approach can be overcome. Many applications can reuse a set of common functionality that is implemented only once into the service layer, and then reused by individual applications and websites. This approach leads to consistent applications, lower maintenance cost, a much improved time to market.

Service APIs also help integrate third party applications consistently and robustly and can help workaround performance limitations if they exist in third party applications. Creating multichannel applications (exposing functionality not just via the web browser, but via iPhone apps, for example) becomes easier when the functionality is implemented in the service API.

01

01.

About Maintance Application

Web services have been around for a while. Terms like ‘Service Oriented Architecture’ (SOA) and ‘Software as a Service’ (SaaS) are very popular, especially in enterprise contexts.

Unfortunately, due to the way services have been implemented and sold in the past, SOAs are associated with high costs and complexity, and are deemed overkill for most web applications. However, services can be applied in more situations than one would think, and they can provide unexpected benefits.

In this article, we discuss the so-called ‘service APIs’ – a term we use to promote a way of implementing web services without the negative associations of SOA. Service APIs constitute a lightweight, pragmatic approach to web services that is applicable in many situations.

02

02.

Service APIs

Each website in an organization uses a separate database and implements its logic. Sometimes, websites share a common central database, but the websites are often still considered stand-alone.

This leads to a number of challenges that companies typically run into:

  • Inconsistency. If website 1 and website 2 both implement a feature for user registration, it is not a trivial task to ensure that both features work the same across both websites.
  • Cost of maintenance. If a feature needs to be changed, and the feature is implemented on multiple websites, the changes need to be made multiple times.
  • High per-website cost. In the event of a new website (e.g a website dedicated to a commercial event, such as the release of a movie or a product promotion), typically a vendor is approached that implements all functionality from top to bottom, not taking advantage of everything that has already been built for previous websites in the past.
  • Time to market. The above challenges have the side effect of increasing the time to market new websites.
  • Vendor dependency. A common problem with top-to-bottom websites is that there is a large dependency on the vendor that implemented the website. It is difficult to attract new vendors to develop new functionalities, and there is a tight coupling between various parts of the system. E.g. in the case of a third party ticket system, its integration into the website is often very tight, meaning that the exchange of either the website or the third party system can be difficult.

    • 03

    03.

    The service API model

    To overcome the disadvantages of the traditional approach, a better model for developing websites is required, one that is more suitable for growth and ongoing maintenance.

    In this model, the functionality that is common across websites is pushed down into a service layer. This includes the functionality that is typically part of core business.

    The websites become smaller, in the sense that they contain less functionality. Instead of reinventing the wheel by implementing common functionality, they use standard functionality that is uniformly provided by the service API.

  • Lower development cost. New functionality is implemented once and reused in many different websites (‘Build once, use anywhere’). Also, entirely new websites are less expensive, as they too can reuse functionality that the service API provides.
  • Less vendor dependent. You must retain ownership of your service API. This ensures that you are in complete control of the functionality that the API provides, and as such, can instruct website vendors to make use of the functionality your API provides.
  • Faster time to market. Because of the availability of a common layer of core functionality, new websites or changes to websites can be developed in less time.

    • DO YOU HAVE A PROJECT?

    Let’s talk about it

    WANT TO GET TO KNOW US?

    Contact us