Monthly Archives: September 2016

13+1 Tips For Smarter RESTful API Development

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

Restful api development tips


For accessing and implementing remote services in applications, software developers have two alternative protocol choices for developing APIs. The first (and the older) option is to go with SOAP (Simple Object Access Protocol) APIs, which fetch data as services. For public APIs in particular though, this approach is no longer that popular. In a recent survey, it was found that 7 out of every 10 public APIs follow the REST (Representational State Transfer) protocol to access web services from the cloud. Not surprisingly, the focus of professional API providers have shifted towards making RESTful APIs, with SOAP APIs gradually receding to the background. In today’s discourse, we will deal with some handy tips for effective RESTful API development:

  1. Using GET for state alteration is a mistake

    This one is a big no-no. In order to make changes in state (or changing states altogether), the POST, PUT or DELETE methods should be used. Calling GET for this purpose is likely to generate errors. New API developers need to have a thorough idea about the functionalities of all the REST API methods before starting to code for interfaces.

  2. Avoid relying on only top-level resources

    You need to keep your APIs simple, and introducing subresources is a great way of doing that. This is particularly important for interfaces that involve a large number of relationships – where using only the top-level APIs can be complicated. In general, any resource that is a part of another (parent) resource can be used as a subresource. These subresources offer two-fold benefits: firstly, within the representation of the resource, the dependency on individual keys is brought down. Also, API customers can understand the resources more easily, when subresources are present. To put it simply, subresources significantly enhance the readability of RESTful APIs.

Note: Most aggregations can also be included as subresources. Make sure that all subresources are located within their respective parent resources.

  1. Versioning is important

    Version changes in an API can be broadly classified under two heads. Firstly, there are the minor version changes, which involve alterations that can potentially affect the performance of the API (for instance, adding HTTP headers on API calls). Secondly, there are major version changes like wholesale changes in the core functionality of the API and/or an overhaul of the URL. Both types of changes can cause loss of service for existing API customers, unless versioning is present. With a systematic versioning system in place (for major and minor changes) you can easily make and track changes in the API – as and when required, without affecting current users.

  2. Nouns YES, Verbs NO

    Unlike SOAP APIs, RESTful APIs make data available as ‘resources’. In such a resource-oriented ecosystem, all elements of the API domain (right from Sales and Clients, to Orders, Documents and Users) should be considered as separate ‘entities’. This, in turn, means that nouns – and not verbs – have to be used in the URL (e.g., POST instead of POST Verbs can be delegated systematically with the HTTP verbs. Each resource needs to be exposed by an API, doing away with the difficulties of actually making endpoints of each specific ‘action’. The HTTP verbs will indicate the action to be performed, while the resources as nouns in the URL will highlight the purpose/functionality.

  3. Keep the URLs simple

    Part of the age-old KISS principle for software development. The more complex a URL is, the difficult it becomes for: a) the providers to make changes in the API, and b) the third-party app developers to use the API. The problems tend to go up further if the number of ‘relationships’ represented in the URLs is relatively large. That’s precisely why it is advisable to make use of designated query strings that would keep things simple, and make the URL more intuitive for the customers. A good approach for doing this is adding all value objects within the query string, and the entities just before the string (the Domain Design Driven approach).

Note: Avoid going beyond 3 levels of relationships (parent-child) in the URL. For deeper relationships, using query strings is recommended.

  1. Specify communication format in HTTP header

    The format of communication should be clearly mentioned in the HTTP header of a REST API. The serialization formats help both the API clients as well as the API developers to understand how communications/network requests would take place through the interface. For listing out all the supported response formats, use ‘Accept’. ‘Content-type’, on the other hand, specifies the exact format of the request. Confusions over the data communication format can seriously hamper the overall usability of a new API.

  2. Design for the user

    Instead of mechanically using the database-driven approach to create RESTful APIs, take time out to jot down the core features and capabilities of the interface first (along with its requirements). In many cases, you will find that using microservices is a much better solution than the traditional database-oriented method. Ideally, an application should have separate bounded contexts, with their implementation not being exposed to users. Customers who need to interact with a specific section/feature of your API should have access only to the corresponding bounded context (making all the data available to everyone makes no point). You need to focus on developing a minimalistic interface that delivers all the desired features, without ever posing a problem for the API customers. User-experience matters in a big way!

Note: The underlying resource(s) in a REST API might be rather too complicated for users. The onus is on API providers to generate a more user-friendly representation of these resources.

  1. Make the HTTP verbs idempotent

    While using any of the HTTP verbs in a RESTful interface (GET, POST, PUT, PATCH or DELETE), there should never be any uncertainties over the likely outcome. This is where the importance of HTTP verb idempotency comes into the picture. Check and double-check that all the methods generate the same results every time, irrespective of the frequency or the number of times they are being called. Remember that all API calls come with a certain expectation on the part of the user – and unless the methods in your API are consistent/idempotent, it won’t be able to fulfill these expectations. The API will suffer as a result.

  2. The importance of HATEOAS

    Yet another factor that can trip up an otherwise good REST API is an over-complicated navigation scheme. HATEOAS, or Hypermedia As The Engine Of Application State, is a principle that addresses this issue well – and hence, should be utilized during the API designing phase. In essence, the HATEOAS approach is all about placing properly working (pre-tested) hypertext links to facilitate smooth navigation within the interface. The use of hypermedia in RESTful APIs is already increasing across the world, and it does offer important advantages.

  3. Use plurals in endpoint names for accessing resource

    This is more of a matter of developer as well as customer convenience. While using plurals for every single resource does not seem correct from a strict grammatical point of view – there are other key advantages of using them over the singular forms (and API developers need not be overtly bothered about grammar in their codes any way!). The use of plurals (e.g., api/users instead of api/user) gives a clear indication of the entire collection of data that needs to be fetched (in our case, ‘user’). Barring a few exceptions, plurals should be used for most resources.

Note: The use of plurals in endpoints is not a rule per se. The important thing here is to avoid mixing up singulars as well as plurals at the different endpoints in the same API. Plurals are generally preferred since they make the APIs more intuitive.

         11. Go for security

API security is one of the most hotly debated topic among software and networking professionals globally. In any REST API, the presence of a valid SSL layer is an absolute must – to remove the risks of unauthorized data access, theft and/or modification. Keep in mind that all that it takes to access a web API is a terminal with a stable internet connection – and not all such connections are secure (at certain points, the data encryption can be incomplete, or worse still, absent). With SSL, all data stored and transferred in the API remain encrypted and organized. In addition, process of user-authentication also becomes simpler. Instead of signing each API call request separately, generalized access tokens can do the trick.

       12. Each resource should have two base URLs

The need for this might not be apparent at first – but it is very important nonetheless. API designers should create 2 separate base URLs corresponding to each resource. One of them will be handling specific (single) values, while the other will be for managing multiple values. This approach helps users keep track of their network requests on a real-time basis. Relying on a single URL for both specific and multiple values increases the chance of errors being returned.

        13. The camelCase vs snake_case debate –

Whether you should use camelCase or snake_case to name the fields depends entirely on the programming technology you are using. As a rule of thumb, use snake_case while working with Ruby and Python, and switch over to camelCase when you create APIs with Java or C#.

Note: According to an eye-tracking study, snake_case is around 20% more easily readable than camelCase. The former is extensively used for JSON APIs.

Bonus Tip: Sometime in 2011, JSON APIs overtook XML APIs in terms of popularity (as per Google Trends). JSON is a leaner, easier-to-parse and easier-to-read tool for data interchanging and access than XML. Unless you are building a REST API that would be widely used by enterprises, it’s better go for JSON-only interfaces.

While working on proxies that do not support all the HTTP verbs (there are some that support only GET and POST), a X-HTTP-Method-Override custom header is required. Choose the underlying API style carefully, and follow standard naming conventions (everything has to be intuitive). It’s important that you follow these best practices for RESTful API development – to ensure that your software indeed delivers the desired solution.



Top 12 Advantages Of Outsourcing IT Projects

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

Advantages of business outsourcing


More than 50% information technology firms across the world outsource their projects, either fully or partially. According to a 2016-17 IT Outsourcing Statistics report, around 40% of application development firms increased the degree of outsourcing last year (as opposed to a measly 9% firms actually reducing their outsourcing activities). In particular, both the level and the frequency of outsourcing is higher in larger-sized IT companies than in startups and mid-sized agencies. Over here, we will highlight some key reasons behind the popularity of outsourcing IT projects:

  1. Doing away with distractions

    Every IT firm or app development company has a core business, which has to be accorded first priority. What’s more, companies – even the largest ones – have limited manpower and technical resources. Outsourcing allows them to avoid keeping these resources engaged on different projects at any time. As a result, they can keep their focus on their main business activity, while the third-party developers they hire can complete projects. It’s all about freeing up resources, prioritizing things, and doing business optimally.

  2. Availability of skilled professionals

    One thing needs to be understood at the very outset – in IT, ‘experience’ is NOT equivalent to ‘skill’. Different projects require varying types of skillsets – and it would be a waste of time, money and learning resources to train your employees every time. The smarter alternative is, of course, looking for a company which already has the necessary skilled personnel to handle the project under question. Through outsourcing, projects can be handled by qualified professionals – without your having to organize in-house training sessions every time.

  3. Moving beyond resource constraints

    If every IT or mobile app agency were to accept only those projects which can be handled with their resources – they would have ended up working on very few projects each year. The reason for this is simple: in such a ‘closed’ environment, the existing resources of a company would simply not allow it to accept projects of various types. Outsourcing is the best way to do away with this constraint, get access to advanced technology (as and when required), and make the best use of them. An ‘open’ company has the capability to take on more, and diverse, IT projects.

  4. Better management

    As a company grows and its scale of business expands, operational inefficiencies tend to creep in. Certain areas remain unattended to, teams might start to lose productivity due to poor monitoring and management, and project budgets might slowly spiral out of control. To keep such risks at bay, organizations often hire IT project management personnel. In exchange of a pre-specified fee, these managers can make sure that day-to-day operations in an office are running optimally, and each project is progressing in the best possible manner.

  5. Objectivity

    If you are an employee of an IT company and are involved in an application development project, it is only natural that you will have a certain bias towards it. During the software testing phase, everything might seem perfect to you – since you are the one who had created it in the first place. The reality, however, can be quite different – and your software and mobile app might be complicated for the general users. This is precisely why objectivity and a clear perspective is required during testing, and a third-party tester/testing team brings that to the table. If you outsource software testing to a reliable external firm, you can rest assured that your app/software will be checked thoroughly and without any pre-conceived notions. The lack of familiarity will actually help in better project evaluation.

  6. Bringing down labor costs and operational expenses

    When you hire a third-party app developer, you will (of course!) have to pay his/her fees. However, these ‘outsourcing charges’ are, in most cases, significantly lower than the overall labor fees and other related expenses that a firm has to incur – if it opts to do all projects on its own (needless to say, the time-crunch will also complicate matters further). By delegating projects to third-party companies, these additional expenses are avoided, and there is no uncertainty over overhead expenses either.

  7. Better quality standards

    As already mentioned above, outsourcing helps IT companies to get hold of superior technology as well as the ‘right person for the right job’. As a result, chances of innovation and discovery becomes higher, and new elements can be implemented in projects to make the latter technically superior. Given the sheer volume of third-party companies at present, it is only natural that each of them focuses on high quality standards to give itself an edge. When you choose the right outsourcing partner, you effectively ensure that your projects will turn out to be better.

Note: On average, 2 out of every 3 tech firms do not find the time to train their employees on a regular basis. With outsourcing, the need for such training is minimized – since projects are actually worked upon by professionals from another company.

  1. New ideas and solutions

    It’s an absolute myth that IT professionals do not need to be creative. While brainstorming for a new app idea, or trying to resolve a nagging tech glitch – it is often important to be able to think out-of-the-box. Outsourcing projects opens up that opportunity. The team to which a project is delegated to can bring new ideas and thought processes to the forefront – something that in-house employees, already busy with their everyday tasks, might not be able to do. A fresh idea or a new way to work around a problem can help the entire project development greatly.

  2. Advantages without commitments

    One of the biggest advantages of working with an outsourcing partner is that, you get all the resource and expertise benefits, without any additional baggage. As an when projects arrive, you get in touch with a third-party company, get into an agreement, get the work done, make the payments, and be done with it. The next time you need to contact that company is when you have to hire its services again. There are no long-standing commitments to worry about. It’s just like paying an expert from outside your company to help you out – only when you need the help.

  3. Great for startups

    A new IT company, understandably, cannot even come close to match up with the setup and resources of an established organization. However, with the help of outsourcing, they can certainly take up projects of the same scale that the big players do. In essence, outsourcing allows the startup companies to ‘think big’, and ‘go big’ with their projects – even when their internal setup is small. Traditionally, new companies have always been at a disadvantage from their larger rivals – and outsourcing removes this by evening out the playing field.

  4. The continuity factor

    The turnover rate in the IT industry is on the higher side (and has an upward trend as well). The BenchmarkPro survey pegged the 2015 turnover rate in this sector at 16.4% – nearly one per cent higher than what the figure was in 2014. While working on a project in-house, if a team-member leaves – that can lead to considerable delays, as a replacement is recruited, trained, and given time to settle in. To avoid such messy scenarios, outsourcing is a good option. The specialist app development company you hire will make sure that projects do not suffer from continuity issues. More often than not, they have trained personnel as backup – just in case some team-members decide to leave prior to project-completion.

Note: With use of advanced technology, availability of more qualified workforce, and minimal continuity problems, outsourcing often helps in speeding up the overall project development cycle.

       12. Risk reduction

The risks associated with a new IT project come in many forms. On the one hand, there are technology-related issues and the rapidly evolving market trends, while on the other – there are things like legal regulations, government directives, competitor analysis, and security considerations. It is one of the main jobs of third-party outsourcing partners to keep track of all the latest developments regarding these. In addition, they are also well acquainted with the tools and resources that are best-suited for a particular project (and one size definitely does not fit all!). Project risks – particularly those cropping up from improper/incorrect/outdated information and sub-optimal utilization of resources – get minimized as a result.

While outsourcing IT projects has many benefits, it should be done with a certain degree of caution. For starters, a company should look for probable outsourcing partners, make a shortlist of suitable agencies, get in touch with them, and then make a choice. Before a project is delegated, all the paperwork has to be completed and things agreed upon – so that conflicts do not crop up in future (mobile app companies generally sign non-disclosure agreements (NDA)).

Outsourcing, when done in a smart, informed manner, offers companies a way to handle projects better – while avoiding increased operations, training and IT costs. Seamless knowledge sharing (between third-party experts and in-house employees) is yet another advantage of outsourcing. In Business 2.0, outsourcing plays an extremely critical role – and its growing popularity is far from being a surprise.

How To Design Your APIs? Here Are Some Useful Tips!

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

API designing tips and pointers


Like every other type of software, the success of application program interfaces (APIs) hinges crucially on the type of user-experience they provide. There is, however, a significant point of difference. While user-oriented software (mobile apps, for instance) need to be easily usable for the general public, APIs have to be accepted by developers – who are established programmers themselves. Hence, there is a certain additional level of technical sophistication required, when you design new APIs. In what follows, we will highlight a few handy tips for efficient API designing:

  1. Know the purpose of your API

    Keep in mind that APIs are, in most cases at least, not technical solutions per se. They are built to serve as tools for web and mobile app developers. Make sure that there is a clear requirement of your API – a unique problem it solves or a specific need it addresses. Instead of focusing on how your API can fit into existing IT setups, think of how it can help businesses in the long run. Avoid making APIs just for the heck of it – that would be a waste of time and hard work.

Note: The name of your API should clearly indicate its functionality. Do not fall into the ProcessData() trap, and stay away from trying to promote your company through API names.

  1. Go for Versioning

    It’s a brand new API, and you have no idea whether there will ever be a need for subsequent versions. Do you still need to use versioning in such cases? Oh yes, absolutely – since top-level versioning would make it extremely easy for you to add fresh versions later and include more functionalities in them, without having to change the API interface (versioning is, of course, free too!). What’s more, if your API is properly versioned, you can get a clear idea of its user-distribution as well. The version of an API should ideally be stated in its URL.

  2. Identify the core features of your API and keep them simple

    There are plenty of areas where an API can trip up, owing to sub-standard designing. However, you should be particularly careful while finalizing the data structure and options in your software, the workflows and data sequencing involved in it, and obviously, the richness of the data used in the API. Do not include too many structural variations and find out how many fields should be present in responses. Within the API workflow, ensure that the user-authentication/authorization flow is transparent and customer-friendly. While adding rich data, keep in mind that making the API layer too heavy can make its development cycle lengthier and also affect its overall performance.

  3. Use HTTP codes correctly

    Stay well away from API development and designing until you have a thorough idea of what each HTTP status codes mean. For a general REST (representational state transfer) API, the most common response codes are 200 (OK), 201 (Created), 204 (Zero Content), 401 (Unauthorized), 404 (Not Found) and 422 (Unprocessable Entity). The 5xx status codes signify refer to server-side errors (just as 4xx responses indicate client errors). Understand and use HTTP codes correctly in your API – mistakes here can introduce serious glitches in your software.

Note: Instead of having to deal with heavy XML processing for transferring data to your API’s endpoints, make use of JSON. SOAP APIs have given way to RESTful exchanges in terms of simplicity (and hence, popularity), and JSON is significantly easier to work with than XML.

  1. Make your APIs more scalable with hypermedia

    As widely discussed in last year’s Nordic API World Tour, hypermedia is the best possible tool for ensuring seamless evolvability in your APIs. Broadly speaking, hypermedia refers to all hypertext extensions for multimedia functionality, and it allows API providers to adapt to the rapidly changing ecosystem of business API requirements – without damaging the existing client applications. At first, the presence of hypermedia might just make an API seem slightly complex to mobile app developers. However, from a long-term perspective and changes that are likely to be needed in future, they have to be included.

  2. Include data caching in your API

    This is particularly important for APIs that need some time to load and execute. API providers mostly opt for distributed caching services, which allow all hosts to access/make modifications in it (as and when required). Avoid using in-memory data caching for every host, since that can make the entire system setup complicated and buggy. It has been proven that APIs with a hosted caching solution in the cloud execute faster and are, all things considered, more efficient.

Note: You have to use HTTP caching headers to define the caching rules for your API.

  1. Consider implementing a rate-limit

    Not a mandatory requirement, but a smart one nonetheless. As the user-base of your API grows, it will be integrated in an increasing number of new workflows and system infrastructure. App developers might make the mistake of introducing endless loops while calling the endpoints, resulting in serious API concurrency issues (such issues from the client-side can even result in your API breaking down temporarily). To minimize such risks, you should introduce basic rate-limits – to specify the maximum number of API calls/network requests within a given time-span – for endpoints that are the most resource-intensive. Make sure that your rate-limits are easily understandable by users.

  2. Formal documentation is necessary

    Technical documentation for an API is no longer an option. The documentation serves as the first point of interaction between your interface and developers who are likely to use it. You need to get your message about the features and advantages of your API across fast – or else, users might move over to another API provider. In addition to the methods, functions, requests, responses and other basic features – make it a point to include a detailed tutorial and multiple examples/Use Cases in the API documentation. It should work well as a guide for developers using your API for the first time.

Note: To find out whether your documentation is good enough, ask the API testers to go through it and then use it to create a basic application within 15-20 minutes. If they cannot do that, that’s a signal that further explanations are required in the documentation.

  1. Include pagination

    A consistent, easy-to-understand pagination system can go a long way in enhancing the usability of your API. For starters, it would bring down the total volume of computations required on the app servers. In addition, pagination would stop non-essential data from being transferred to clients. Choose from the different patterns available for pagination, depending on precise nature and likely usage of your API. All the timestamped pages in the API need to have links to more pages. That would ensure that pagination requests do not return duplicate results, even when the concerned objects have been modified.

  2. Know your way with the HTTP ‘verbs’

    We have already spoken about the importance of the HTTP status codes. Equally crucial are the so-called HTTP verbs, during the creation of any standard REST API. POST is used to create a new resource, PATCH is specified for the updation of already existing resources, GET is called for data retrieval, while for deleting a resource, the DELETE verb is used. There are several other common HTTP verbs as well, and they help developers while using new APIs.

Note: Avoid trying to use the GET request to to make data modifications. It is meant to be used only for retrieving data, and not for making changes in it.

      11. Use annotations and markers

Are you making a private API or a public/open API? Is authentication required on it? Create and use custom annotations and markers to clearly specify these issues. Both authentication requirements as well as the degree of access control can be managed with markers/annotations. To gain further information on the user calling an API, the markers need to have additional ‘context objects’. Yet another advantage of using markers and annotations in APIs is that, they can easily classify network requests on a granular level, based on user-profiling.

     12. API security should be a prime concern

If the security features of your API are suspect, it is almost destined to fail. Instead of providing your API exclusively under HTTP, go for simultaneous HTTP and HTTPS support. You can even consider offering your API only under HTTPS (this is increasingly being done by leading API developers across the world). Use ‘throttling’ methods (e.g, a 503 response) to protect your API’s performance from getting affected due to a huge number of requests from single users. Be wary of the many other forms of Denial-of-Service (DoS) attacks. If your API can promise (and deliver!) complete security assurance, nothing like it.

Note: Cross-site Request Forgery, or CSRF, is another serious black-hat security threat for APIs. The risk is particularly big when the interactive users use the same authentication configuration that is accepted by the API.

In addition to the above points, make sure that you follow the four rules of thumb while creating your API. Firstly, make your API highly reliable, with minimal system downtimes. For public APIs (which are rapidly growing) set up a transparent API monetization model and deliver high longevity. Next, share the best practices of using your API with its target users (i.e. the developers). Finally, design your API in a way that ensures that users have optimal ‘control’ over it. You can do this by letting developers download and store API data in their local servers, instead of having to depend on cloud operations at all times. Make APIs easily ‘discoverable’, and provide robust, round-the-clock developer support (with SDKs, references, pricing issues, and more).

Remember one thing: most API complexities need to be managed by you, the provider. Deliver a great user-experience to developers with your API – that’s the best way to pave the path for its success!


Top 10 API Security Threats You Should Be Wary Of

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

How to manage API security risks?


Instances of cyber hacks and software attacks are increasing at an alarming rate. In 2015, the year-on-year spike in the total number of ‘zero-day vulnerabilities’ (instances of cyber attacks for which fixes were not yet available) jumped by more than 125%. Like any other piece of software, APIs can also be compromised by these hack attacks. Since APIs serve as channels that expose applications for third-party integration, the applications can also come under security threats. Over here, we have outlined some common API security issues that you need to be careful about:

  1. Poor coding

    As an API developer, if you try to take the short way out by following the so-called ‘Just Enough Coding’ route, your API(s) might get exposed to serious vulnerabilities. The risk might not be apparent at first, since the concerned API might be doing okay on the usability and the functionality fronts. However, poor coding standards will not allow proper integration of API(s) with the overall platform/ecosystem. Problems can arise from multiple errors – right from absence of ‘type checking’ (which allows uploading of any file and deployment of the app on the server) and memory overflows, to incorrect error handling methods and even choice of the ‘wrong’ language for coding. You need to take time out to get a hang of how your APIs are meant to work and how customers would use them. That will help you in coding properly. If you rush too much to release your APIs, the latter might suffer.

  2. Weak validation

    For ensuring the security of web APIs and clients, validation of concerned SSL certificates is essential. However, developers often make the folly of making this validation process rather half-baked – as a result of which hackers can issue their very own bogus certificates (all that’s required is a working net connection), get random users to validate on these, and access confidential user information (breaking into the the encrypted data transfer process). Malicious API traffic interception and the ‘weak validation’ on fake certificates can deliver API keys, passwords and usernames right in the hands of hackers as well. Set up the data encryption and validation methods based on the sites that the web client will access. For iOS applications, consider ‘key pinning’ to keep things more secure.

  3. Uncertainties over enterprise API usage

    While on the topic of API validation, we should mention the risks that enterprise APIs might be subject to as well. In many large-sized companies, the administration fails to track who is using the enterprise APIs, how heavy is their usage, and the reasons they are using the APIs for. As a result, the usage charges remain unverifiable and can also spiral upwards. Since there is limited (or no!) information on the applications and/or the systems that are using the enterprise APIs, changing the API provider (as and when required) becomes a tough ask too.

Note: Many employees tend to access APIs with their enterprise credentials. If these credentials are exposed to unauthorized parties, that can put the API in particular, and the enterprise in general, under serious security clouds. For smart enterprise API management guidelines, click here.

  1. Whose responsibility is it, anyway?

    The API provider prepares the initial version of an API, the API Developer extends it with features and functionalities, and implements it, while the API customer uses it to create applications. Now, security should always be the responsibility of the person/team at the lowest level – the API providers or developers. Things like user authorization and authentication, API versioning and dependency management need to be handled by developers. Putting it in another way, adopting developer-centric API security norms is important. API customers can put in additional security layers (SSH, HTTPS, SSL, etc.) – but they are only of use when the developers have ‘securely’ designed the software.

  2. The risks of using SOAP/XML

    Make no mistake, most vulnerabilities from the server-side can be easily tracked and fixed in SOAP (Simple Object Access Protocol) APIs. However, the XML data format – which is bundled in with the SOAP protocol – has several ‘soft targets’ for hackers, like Denial of Service (DoS), attacks by external entities, and even problems in XML encryption. The fact that the SOAP protocol remains in production for extended periods due to heavy system dependencies complicates matters further. Unless you are working on a corporate API or a software legacy system, it makes a lot of sense to ditch SOAP/XML in favour of the much simpler JSON/REST (Representational State Transfer) combination. The potential security threats will be much lower.

Note: If you HAVE to work with SOAP APIs, make sure that the API audit prior to release is thorough. All vulnerable endpoints in the stack have to be found, and patches for them created, before the API is made available to customers.

  1. Enterprise API misuse

    This can be both intentional and unintentional. Let’s explain this risk with a simplistic use case: Employee A uses the enterprise API for a particular service (say, downloading a picture). Now, Employee B also accesses the API and avails the same service (in our case, downloads the picture which is already the property of the enterprise). Such redundant and repetitive API usage can go on, if not tracked by the company. As a result of such API misuse, many corporate houses end up facing a much higher bill than what they should ideally have to pay. Having an strong API governance setup at the enterprise level is important, and API providers need to monitor the usage of the interfaces constantly as well.

  2. Lack of security in the transport layer

    Absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-have-s’ in a secure API. Unless a TLS is used, risks of the fairly common ‘Man-In-The-Middle’ attacks (where an unauthorized third-party can intercept the transferred data and modify it) remain very high. Use both SSL and TLS in your APIs…they are neither too pricey or too complicated, and they go a long way in removing basic API vulnerabilities.

  3. Too much control with customers

    When can you say that your API is 100% secure? That’s right – when it is yet to be accessed and used by a customer. As soon as network requests (API calls) start coming in, the API gets exposed – and if you let customers use your APIs in whatever way they like – a hack attack might be waiting just around the corner. Many APIs do not set any specific password complexity rules, do not track the API metrics, or allow repeat session ID tokens. Remember that while most of the users are genuine, there can always be a handful of miscreants, looking to use your API to illegally usurp user-data and maybe even introduce bugs in the system (the ‘black-hat hackers’). Set limits on concurrent API connections, implement password length/complexity requirements, make re-authentication mandatory for extended usage, and be very careful while analyzing the API usage metrics. If any suspicious activity is detected, find out the reasons behind it.

  4. API terms of use not considered important

    Yet another security glitch that often bugs enterprise APIs. The threat stems from two sources: firstly, Final-users are not aware of the terms of service (ToS) of an API – and end up using them for purposes/in systems that they are not allowed to. Data ownership in enterprise APIs is also specified in the terms of usage. Secondly, when customers do not pay attention to the API terms and conditions, they often remain unaware of the quality of service the software is likely to deliver. That, in turn, results in improper data tracking on the customer-side. With APIs growing in importance for businesses worldwide, these visibility issues are going down…but they still present a threat.

  5. Insufficient security at endpoints 

    Leading API developers recommend the inclusion of ‘key signing’, ‘hashes’, ‘shared secrets’ and other such common endpoint hardening technologies within the API development cycle. Making changes at a later stage is difficult – since the legacy systems which use the API might suffer performance issues. In case the endpoint hardening is not done during the early phases of API development, it might not get done at all. As a result, the endpoints will remain vulnerable – and any competent hacker will have a field day.

The rapid evolution of the API economy throws up threats of its own. As we move on from basic backend-as-a-service (BaaS), to software-as-a-service (SaaS) and Infrastructure-as-a-Service (IaaS), new technologies, resources and API frameworks are becoming available. While technological advancement is a positive thing per se, using the latest tools without proper training and/or limited understanding of how they work can be counterproductive. The mindsets of API providers have to evolve as well, for optimal use of the new technologies.


The onus is on API developers to list out all possible ‘security holes’ in their software – which can be targeted by attackers. Once that is done, steps can be taken to block out these risks systematically, and make the APIs well and truly secure.



7 Reasons Why You Should Build API Driven Solutions For Your Mobile Apps

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

The importance of api-driven app development


It won’t be overstating facts if APIs were referred to as the ‘foundational technology’ behind application development. API-driven development methods were in focus since the start of Web 2.0 technology, although the attention on APIs has really spiked in the last half a decade or so. APIs bolster the performance of mobile apps in two chief ways. Firstly, they help in the seamless integration of applications with the internal IT systems in the backend. Also, apps can be connected with rich clients on the front-end without any hassles, with the help of custom APIs. In today’s discussion, we will delve a little deeper into the need for API-driven development for smartphone apps:

  1. Optimal use of developers’ time

    Writing endless lines of codes for an app is ‘hard work’. Working with pre-built, custom application program interfaces is ‘smart work’, and you should already be aware of which one you should opt for in today’s world. You might be the best mobile app developer going around, but a reluctance to use APIs will only stretch out the overall app development cycle, necessitate more (read: much more!) coding, and keep the risks of making errors wide open. APIs give developers the option to ‘destroy code’ as much as possible while creating high-quality applications. The time saved over here can be utilized for other productive purposes.

  2. Closer collaboration between app makers and clients

    Earlier on, most forms of software development were long-drawn processes, and they did not really involve the customers. The attention was more on the functionality of apps in their final stage, with client-feedback and suggestions staying in the background. The growing popularity of API design and development has revolutionized this scenario. Now, developers can actively seek the feedback/opinions of clients at multiple stages of development. The same can then be easily incorporated in the project. What’s more, customers can even get a first-hand feel of using apps BEFORE they are launched – through service virtualization techniques with APIs. In a nutshell, APIs have become instrumental for narrowing down the gap between clients’ expectations and the developers’ output. And that’s a good thing for both parties!

  3. Better organization

    When you are working on multiple mobile app development projects, the last thing you can afford to be is unsystematic. Keeping things in order is one of the most important reasons that drive up the adoption of API-driven solution methods. Provided that all the API descriptions, API schema, usage-related data and other specifications (including the formal API documentation) is securely stored at one place, accessing the right information at the right time becomes a whole lot easier for developers. The need for having a properly detailed schema, in particular, boosts the app testing procedure.

  4. Getting rid of repetitive steps

    With a strong API backend (backend-as-a-service or BaaS), most repetitive steps during the making of an app can be unified. All that the developers have to do is connect the paired SDKs (Android, iOS, Javascript, Python, Java, Node,js, and others) with the APIs, and get projects completed more quickly – while maintaining high quality standards. With new technologies and frameworks being launched frequently and mobile app development increasingly becoming more complex, APIs provide a smart way for developers to build apps faster, and pay more attention to the core features and the main point(s)-of-difference of new applications. There is no need to reinvent the wheel every time – the focus should be on making sure that the wheel rolls smoothly, always.

Note: Both boilerplate code lines as well as repeated stack setups can be removed by following API-driven development methodology for every application.

        5. Implementing important third-party services and functionality

How do multiplayer mobile game apps allow users to send invites to their Facebook friends? That’s right, by calling the Facebook API. Use on-demand cab service applications (think Uber)? The maps displayed in them are shown by calling the Google Maps API. Now imagine that APIs were not available, and you had to incorporate these functions through code-sharing (from other applications). It would have been an unnecessarily complex process, a wastage of both time and effort (without any guarantee of proper performance at the end of it all). Third-party apps, can, with APIs, share many key functionality of the biggest service providers in the online business. It’s like having access (albeit limited) to the readymade resources prepared by others.

      6. Evolution of enterprise application development

There was a time when developers were not concerned about app-to-app integration (i.e., the internal resources and information of an application being shared by other apps). Things have come a long way from there – and now developers can easily support such integrations with the help of RESTful API designs, access control (key-based) and versioning. JSON-based data has also emerged as handy resources/tools in this regard. These API conventions have successfully replaced the external middleware required for such integrations. In addition, for enabling rich mobile clients and/or JavaScript and HTML5, a robust API architecture has become essential in dynamic application delivery models. If you wish to make enterprise apps that would truly foster better internal and external collaboration, working with APIs is no longer just an option.

        7. Faster and more thorough mobile app testing

Manual testing is necessary, but is far from being sufficient for ensuring the quality of new mobile applications. In general too, thoroughly testing an app without APIs is an unduly long, and often half-baked process. With APIs, developers can use the ‘Test Automation’ feature to perform exhaustive app testing, and bring down the duration of the total app testing cycle at the same time. The pressure on manual testers gets considerably reduced. Chances of bugs remaining undetected is nil, and the apps become of assured quality. As a result, they can more than live up to the expectations of both clients and end-users.

APIs help mobile app developers to create a strong network ecosystem, in which they can develop software. Many apps need to capture and display data from the backend, and APIs are a must-have in them. Another point to be noted here is that APIs in particular, and BaaS in general, are important when you make your first app – and they become even more important when you become an established player (as the needs for higher quality apps and quicker development cycles grow). Not surprisingly, many leading mobile app companies specialize in custom API development as well.

The value of the BaaS market worldwide has been projected to inch towards $7.8 billion by the end of 2017. APIs help developers in multiple ways, and boost up the quality and performance standards of applications. Unless you use API driven solutions for your mobile apps – you are simply risking yourself being overtaken by competitors who have already switched over to the API economy.

Top 13 Tips On How To Optimize Your API Strategy

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

The importance of APIs – often dubbed as the ‘fossil fuel for the next generation’ – is growing rapidly in the world of business. In a recent survey, it was found that around 72% of all enterprises already have well-defined API strategies in place. What’s more, 1 out of every 2 companies were generating (or were likely to do so within a year) significant revenue from their API programs. However, these stats do not automatically mean that working with APIs will guarantee big success for your organization. A properly optimized API strategy needs to be in place, and the following tips should come in handy in that regard:

  1. Understand the need for an API strategy

    Let’s get this one sorted out at the very outset. Don’t go for an enterprise API program simply because ‘all the others are doing it’. Take out time to analyze how an API strategy would help the core product/service development processes at your company. In other words, avoid focusing on the standalone value of APIs (unless, of course, you plan to offer APIs as final products), and consider how they are going to complement your business. Only if you find that there is a demand from customers, or a scope to network better with partners/collaborators, or even for building up a stronger mobility platform and ecosystem, go for an API strategy. Keep in mind the potential risks (security, quality, etc.) as well.

Note: With APIs, you can turn your business setup into an infrastructure-as-a-service (IaaS) architecture – building up your overall reach in the process.

  1. Get an idea of the API value chain

    For make your API strategy successful, you need to know the flow in which APIs are used. This is referred to as the ‘API value chain’. It has the existing backend systems/enterprise IT systems at the first block. Next up in the chain are the API providers, who create and deliver the interfaces to the web/mobile app developers. The latter use the APIs to create client applications. These, in turn, are downloaded and used by the end-users or the general public. So, the ‘API value chain’ looks something like this:

Backend architecture → API Providers → Application Developers → Client Apps → Final Users


  1. Do a cost-revenue analysis

    Remember that APIs do not have (in most cases) any intrinsic value. They are NOT technical solutions per se, but are meant to serve as important components in your overall business strategies. As such, it only makes sense that you should estimate the net returns from developing and implementing an API program. Calculate the overall costs of building the APIs – based on the total resources used up and systems engaged in making them, and compare that with the additional revenue channels that are likely to open up due to the innovations brought about by your strategy. Customize your API strategy in a way that your revenues are always (significantly) higher than your costs.

  2. Study the importance of API version control

    Having an API strategy without a version roadmap is like trying to control a rudderless ship. There can be heightened security threats, app makers can start using them to make applications (and make changes in the API themselves), and outdated APIs can get dragged along for too long. As the API entrepreneur, the onus is on you to settle on a version control system for your application program interfaces. Plan how your APIs will be tracked and monitored (consider all the measurable metrics), what the security protocol and related updates would be, and how you will retire/phase out the older APIs. For that, you will also need to have an idea about the four stages in an API lifecycle:

API Analysis → API Development → API in Operations → API Retirement


  1. Pay attention to the technology

    From a purely technical perspective, there are several choices to be made when you are laying the blueprints of an API strategy program. XML or JSON can be used for data formatting purposes, you can go with either the experience-based or the resource-based design guidelines, and obviously, take a stand on whether to go for SOAP (Simple Object Access Protocol) or REST (Representational State Transfer protocol) APIs. Whatever may be your final choices, make sure that they are taken with an eye on the long-term viability of your business. Remember that APIs are not short-term fixes, and the ideal API architecture for one company is not likely to be suitable for another enterprise.

  2. Public APIs vs Private APIs

    You have to specify the target developers who would be using your APIs to churn out applications. For that, depending on your company’s requirements, you have to decide to go with either Private APIs or Public APIs. The former are meant to be used only internally within an organization – by in-house developers for their own projects. Open APIs (as Public APIs are generally referred to), on the other hand, are accessible by third-party developers for making apps. While Private APIs are more ‘inward-focused’, the Public APIs are instrumental in making the maximum use of the existing IT assets of enterprises. Find out which type of APIs will be best suited for your business, and decide accordingly.

Note: Designing public APIs is trickier than doing the same for private APIs, particularly from the security viewpoint.

  1. Know the role of everyone in an API program

    It’s all very fine to have an API strategy on paper. However, it’s an entirely different ball game to actually implement it within your enterprise. Not engaging the right personnel in the right roles in API management is one of the biggest reasons for the failure of many enterprise APIs. The enterprise architect(s) should be working as the lead managers in your API strategy, overseeing the development, designing, modifications and deployment of APIs (along with their backend integration). Product managers should double up as the connection/communication channel between the ecosystem of API developers and API customers. The responsibilities of maintaining the API architecture should be taken by the system administrator(s) of your company. Other important team players involved in your API program include API testers, senior software engineers, internal/external app developers, and other stakeholders.

  2. Build a MVP version of your API

    Think of it as a beta release of your APIs. It is never advisable to release the final version of an API and then make changes in it (that affects the way in which the APIs are used by those who make apps as well, diluting the overall scenario). Instead, you should look to release a MVP (Minimum Viable Product) version of your APIs as quickly as possible. Make sure that it is accompanied with proper formal documentation, terms of use, a user-friendly sandbox/public endpoint, and a robust security setup. The MVP can be initially offered to in-house developers, before it is rolled out to business collaborators, who can become customers of your APIs. Monitor the feedback received by the MVP, implement the required changes, and then release the full-blown version 1.0 of your API.

  3. Select the right API design style

    Designing an API that would deliver value to your enterprise is not the easiest task in the world, and going with a wrong design model can further complicate matters. Based on your business goals and pre-specified API visions (i.e., how APIs are going to boost your business operations), you can choose a Pragmatic REST model, a True Rest (Hypermedia) design model, or a Web Service Tunneling model. With the importance of Internet of Things (IoT) rising, many enterprises also opt for the Event-driven API designing style. Make sure that the API design strategy you pick will make the interfaces in sync with your backend systems.

  4. Manage the layers

    Familiarity with the architectural design is vital for optimizing the overall API strategy for your business. The design, of course, has to be deployed in the core infrastructure of the API, for proper functionality of the latter. Broadly speaking, the data contained in APIs need to pass through 4 layers. The first is the Security Layer – where security standards and authentication tools (OpenID Connect, OAuth, etc.) are deployed. Next comes the Caching Layer, which keeps a tab on the total API implementations, by managing common requests with cached responses. The Representation Layer is the third in the API architecture hierarchy, where the focus is on presenting your APIs in a easy-to-understand form to target developers, so that they can make the best use of the APIs. Rounding off things is the Orchestration Layer, where multiple backend systems can be managed, and data from several sources (APIs) can be securely clubbed together.

  5. Pay attention to the API Gateway

    An API strategy might be good in theory, and it might even have a captive developer audience (a ready set of customers). However, all the good work might be undone, if you are not careful while creating the ‘API Gateway’. The gateway is supposed to deliver all the functionalities included in the core API infrastructure – right from orchestration and caching, to data security and access control. For an API program to be usable, its gateway needs to be very carefully developed.

  6. Shorten the API development cycle

    This won’t happen overnight, but as your business expands and demand for APIs increases, a shorter development cycle will become very important. Settling on a well-defined ‘API Practice’ is the best possible way for doing this. The standard methodologies, tools and standards should all be mentioned in this API Practice, together with an overview of the roadmap/version control of the interfaces. There are several web-based frameworks and API lifecycle management tools (software-as-a-service, or SaaS), which help in establishing a proper API Practice for enterprises. The main use of this is shortening the development cycle by standardizing the overall process and ruling out uncertainties as much as possible.

  7. The overall quality factor

    Having an underperforming API out there can prove to be counterproductive for your business (in the form of faulty marketing, production glitches, and even loss of external developers/customers). You need to ensure that APIs are easily pluggable to multiple systems simultaneously, are scalable and available, and handle high volumes of network requests (API calls) without any problems. Be careful about the fault tolerance of your APIs as well – as significant API downtimes are likely to create a negative impression on customers. Quality is, by far, the most important concern among API providers – and the problems often get exacerbated due to inabilities in finding the root cause and/or employing the wrong set of people to fix API issues. Perform all the standard API testing procedures – unless your APIs are good, your strategies won’t work!

Like any other business venture, setting up an API program represents an investment by your organization. The focus, hence, has to be on earning a profitable return from this investment – and that is precisely where the importance of API strategy optimization comes into the picture. Around 8 out of every 10 enterprises with 10000+ employees manage to earn $5 million annually, from APIs. Clearly, there are rewards aplenty for a well-managed API strategy, and these tips should get you started in the right direction.



Data resource:

Enterprise API Management: 12 Things You Need To Know

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

Business enterprises are moving towards a centralized ‘API economy’ at a rapid rate. It has been predicted that, by the end of 2018, more than 85% of all the large enterprises across the globe will set up their very own API programs*. The move towards enterprise APIs is fueled by a number of factors – with seamless information exchange and possibilities of better collaboration within organizations being right at the forefront. With growth of use of APIs in the corporate sector, the importance of efficient enterprise API management is also increasingly coming into focus. Over here, we will point out some of the most important points in that regard:

  1. In-premise and on the cloud availability

    Enterprise APIs need to be simultaneously available on-premise as well as on the cloud network. This enhances overall usability, since users are able to access additional resources (as and when required) without any problems. What’s more, switching over from the on-premise API model to the cloud API model also becomes easier. The key lies in ensuring that the enterprise API system can operate on both the platforms without requiring any modifications.

  2. Thinking beyond ‘closed’ enterprise IT systems 

    Information is of the essence in the present economy, when a company offers products or services for sale. The traditional IT system in enterprises is focused more towards protecting and maintaining the internal information database only. APIs, on the other hand, give an option to create an ecosystem where transactions can take place. With application programming interfaces specifying protocols and online service standards, they are, not surprisingly, being adopted rapidly by web-based enterprises.

  3. Selecting the right API tier

    Enterprise API management is much more than creating a standard, ‘one-size-fits-all’ API, and then hoping that it would work like a charm for all companies (it won’t!). The onus is on business entrepreneurs to select the custom API tier and strategy, that would enable their firms to create more value internally, and deliver more value to customers and other stakeholders. Startups should ideally go for the Open API tier, which can provide them with large-scale business recognition and exposure. More established enterprises, on the other hand, can have a combination of a customer-only API tier (that has all important transaction data) and an internal API tier (with the proprietary, confidential internal information). Since Open APIs can be accessed and used by anyone, they can somewhat dilute the brand image of larger companies.

  4. Need for API management at enterprise level

    We are in the midst of a ‘mobile-first’ generation. Now, there exists a gap in the latest mobile interfaces used by customers, and the established backend systems in place at workplaces. Also, the rate at which enterprise backend systems can be modified is different to the one at which business apps and APIs evolve. To bridge this gap, there is a need of a smart enterprise API management layer, that would help to transfer the full value of backend systems to the mobile interfaces.

  5. API-first model vs Backend-first model

    In a service-oriented architecture (SOA) system, this is no longer a debate. It is almost mandatory for API providers to adopt an API-first design approach. In essence, this means creating a smooth, functional and powerful interface to start with, and then hooking it to the backend logic setup (the traditional approach puts more importance on the backend, and relegates APIs to almost an afterthought). The API-first approach works well on two fronts – firstly, API testing becomes a lot less complicated, and secondly, the API implementation process remains thoroughly defined and documented. A backend-first model muddles the very existence of enterprise APIs.

  6. The biggest players with API programs

    Think that use of APIs for businesses is a ‘new phenomenon’? Well, that’s not much more than a myth. From the early years of the millenium (2000s), leading online shopping portals like Amazon and eBay have been working with APIs. Coca Cola and Cisco are two other biggies that entered the API-driven growth strategy at a fairly early stage. By the turn of the decade, online entities like Google, Twitter and Facebook had all adopted enterprise level APIs.

Note: The main objective of enterprise APIs is to deliver competitive advantage to the company which has them, over its rivals (who don’t have API programs yet). A classic example of this is the Netflix vs Blockbuster tussle. The latter had a healthy lead in terms of value till the second half of 2008, when Netflix announced its API to revolutionize its core business. Since then, it pulled ahead of Blockbuster (which did not have an API). By 2010, Netflix was soaring while Blockbuster was hurtling towards its end (acquired by Dish Network in 2011).

  1. Opening up to external ecosystems

    Buyer behaviour is hard to predict. There also remains considerable uncertainty regarding demand fluctuations over time too. In order to deal with these, more and more companies are using APIs that open up their information systems to external ecosystems, comprising of third-party coders, mobile app developers, testers, analysts, and the like. As a result, all the necessary experiments and surveys can be conducted with the help of the information assets at the disposal of companies. The degree of third-party information access can be controlled too. Firms that open up their ecosystems with APIs typically share their revenue-streams with third-party developers.

  2. Growing complexity IT operations in the corporate domain

    Search all you want, but you are not likely to find any software developer or any other IT professional who would say that the architecture of computing systems in his/her company is growing simpler over time. More systems and technologies are getting added, more teams are being plugged in to the development cycle – and deadlines are, understandably, getting stretched. A business API, or more simply, a business interface, can tackle these problems with ease. It can also upgrade existing applications and systems (which might otherwise remain overlooked). Enterprise API management refers to the way in which owners interact with their business, to make it more efficient, clear and simpler. It is not just about programming for business.

  3. API monitoring and assessment

    Like any form of software, APIs can also fail. If persisted with, a buggy API can cause significant loss of revenue for businesses. That, in turn, brings to light the value of analysing the available API metrics on a regular basis, to track progress and assess results/outputs. By tracking the analytics/metrics of an enterprise API, two things can be monitored: a) the API itself is working as it is meant to (the technical perspective), and b) the API is indeed creating innovations and generating value internally and externally (the business perspective).

  4. What do enterprises want from their APIs?

    We have already highlighted the main needs for having an enterprise API management layer in place. Let us now turn our attentions on what actually the big enterprises are using their APIs for. In a Layer 7 survey, it was revealed that 72% of the respondents created APIs to bolster the performance of their in-house mobility systems. This was closely followed by the demand for better integrations with business partners via APIs (70%). Over 65% enterprises expressed their willingness to develop cloud-based APIs. Interestingly, around 55% of the respondents wished to create third-party app developer communities with APIs.**

Note: The demand for APIs by in-house developers for their own projects ( ~67%) trumps that for developing external developer ecosystems, however.

        11. Types/Models of Enterprise APIs

 Apart from the broad API tiers, a company needs to choose the correct enterprise API model for itself. They can either go with private APIs, which are accessible only by authorized partners and developers, or public APIs (open APIs, mainly opted for by startups). Regarding the revenue model, there is the option to select either a revenue-sharing model, or a flat one-time fee model, or the free model (which is followed by Google in most cases). On top of it all, there needs to be a stable, reliable API governance system in place.

      12. It’s all about the ‘ilities’

An enterprise API needs to have certain properties, without which it would cease to be of any value to its parent company. The first of them would be ‘availability’, which refers to minimal downtimes and consistency across environments and platforms. Next up is ‘reliability’, which would make sure that any number of API calls can be handled, without performance being affected in any way. The third cog in the wheel is ‘scalability’, which deals with whether the API can be expanded in response to larger volumes of network requests. Finally, there is the need for ‘discoverability’, which means that all developers and users can access the API without any difficulty (herein lies the need for a stable central service repository).

Software engineers and mobile application developers agree on the importance of continuous API refactoring – in a bid to improve their user-experience levels over time. High-end security assurance is an absolute must-have in enterprise APIs, and while designing them, providers should implement systematic versioning. Companies need to build strong help and support communities for their APIs on social media channels too.

The success stories of big players like Google and Netflix after they started working with APIs are well-documented. What’s more noteworthy is that, more than 50% of all small businesses/startups will have their own mobile applications by 2017. In such a scenario, the adoption of enterprise APIs is only expected to rise further, and managing them will be crucial for realizing their potential value.


*, ** Resource:

Top 15 App Ideas For 2017

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

In February 2016, the total number of apps available for download at the Google Play Store touched the 2 million mark. It took a little longer for Apple App Store to reach the milestone, which it finally arrived at in June. Given the sheer variety of iPhone and Android applications currently at the online stores, it is not the easiest task in the world for mobile app developers to come up with new and innovative ideas – which can actually be transformed into meaningful, useful apps. Today, we take a look at some interesting app ideas, which might well be worked upon in 2017:

  1. Personalized recipe app

    No, we are not talking about yet another application that lists hundreds of standard recipes for users. Instead, there can be an app in which people would be able to enter the names of ingredients – and in turn, the app would display the possible dishes that can be made with them. The biggest utility of such an app (can be made for both iOS and Android) would lie in the fact that users would get new recipe ideas with the ingredients they already have – instead of having to step out to buy stuff. A nominal amount would have to be paid for downloading recipes. Professional chefs as well as others interested in cooking will have the option to upload their own recipes on the app, for a certain pre-specified fee.

  2. Bus timetable app

    This one would be for the daily commuters – to school, college, workplace, anywhere. The app would remove the uncertainties and sheer frustration of having to wait at bus-stands for several minutes (not to mention that feeling when you ONLY JUST miss a bus!). Based on the destination entered in the app, it would throw up bus numbers and the times they are expected to arrive at the bus stops nearest to users. In addition, notification alerts will be generated when 3-4 minutes remain for the scheduled arrival of a bus (a strong backend API support, along with powerful GPS integration will be required). That way, people will be able to step out of home and arrive at the bus stop…always at the right time.

  3. App for buyers 

    We have plenty of mobile apps for sellers – where sellers can place ads of their products/services, have customers get in touch with them, and generate fruitful sales/business leads. How about having a mobile shopping app that ‘thinks’ from the buyers’ perspective. That’s right, it will be pretty innovative if there could be an application where buyers would be able to post their demands (along with pictures (if possible), specifications, and preferred price range). Vendors who sell those products would be able to contact buyers and complete the deal. A handy option for buyers, and an opportunity for sellers to take a pick from multiple trade options. This app will be a ‘win-win’ tool for all parties concerned.

  4. Medical information app

    A health app that would make all the important health information available to users, in the matter of a few taps. There can be a provision of linking a person’s unique ID (say, Passport or Pan Card) with all the medications (s)he has ever been prescribed in his/her lifetime. In addition, medical history of family members will also be uploadable. This would make it easier than ever for doctors to understand the case history of patients as well as to gauge the possibility of any hereditary diseases. What’s more, insurance agents – by paying a certain fee – can access the medical information of clients.

  5. App for activating home appliances

    With all the buzz about Internet of Things (IoT) at present, interest in creating ‘smart homes’ is likely to spike further in 2017. It would be a cool idea to create an iPhone paid app, that would be paired with a specially designed ‘smart switch’ – for switching on common gadgets and appliances at home. For instance, the app can be used to turn on the heater, switch on the refrigerator, or even put on the electric kettle. There should be a customized version of this app for Apple Watch too.

  6. Story contribution app

    This one won’t be like the many mobile storytelling apps out there, which already have a certain number of stories in them (either free or through paid downloads). Instead, on this app, a user will have to start a story, write a few (say, 60) words, and then leave it in a ‘new story thread’. Another user, from anywhere in the globe, can pick it up and write the next 60 words. The story would expand in this manner, till a final word limit (1000, for example) is reached. User-curated storytelling app with a difference!

  7. Brand/product profiler app

    This can be built like an app for shoppers. At a large shopping outlet, products of many brands are displayed – and it is often tricky for buyers to make a choice from them. With this app installed in their handsets, all that they would have to do is point their smartphones in the direction of any product. The app will read off the product brand, and instantly display a brief history of the brand, current reputation, and a few selected customer reviews for the concerned product (if the product is a brand new one, the reviews would be for the brand). With more information at the fingertips, choosing the best products at shopping malls will become easier.

  8. Charge sharing app

    Let’s just accept this – the battery performance of smartphones is not going to become great anytime soon. We have all faced the problem of our smartphones running out of battery at the most inappropriate of times. With a charge sharing app, users will be able to send out a ‘share charge’ request to all smartphone-owners within a small radius. The person who picks up a request will have to fulfill it (a certain payment will be required for the charge shared). In addition, the ‘charge suppliers’ will have the final say on what percentage of battery power is to be shared. With an app like this, chances of your phone dying at any time will become just that bit lower.

  9. Picnic planner app

    How often have you been confused about where to head to for a day out with your family? A custom picnic planner application (can be made for iOS, Android and Windows Phone) should put an end to such problems. Once you put in the preferred duration of your day trip and your budget details, the app will show multiple attractive picnic destinations (which fit your choice). Tapping on the picture/name of each place would display a screen with a brief description and list of tourist attractions over there.

  10. App for flirting/dating

    The frustration of finding a person of the opposite gender attractive, gathering up enough courage to strike up a conversation with him/her, and finding that (s)he is already engaged is…well…understandable (!) for people who have already suffered such misfortunes. At a party or any social gathering, a person will have the option to mark him/herself as ‘I’m Single’. Next, (s)he will be able to view the profiles of other such ‘single’ users. No chances of suffering a heartache here – the app would make sure that people who are looking for a date would indeed find a suitable person, without any hassles. Users will have the option to specify whether they are looking for a one-time date, a limited-period fling (summer holidays, for instance), or a long-term relationship.

  11. App to play your favourite music at public places

    You step into a restaurant, music videos are being played on the beautiful television screens over there…and you do not like the music one bit. By 2017, there should be at least one app (probably more!) to change this. Users will be able to start their favourite YouTube music videos and point it towards the televisions/music players at such public places. The YouTube API will get added to the query, and your favourite video will be added to the playlist. Users will also get the option to view and upvote any video on the playlist. If your favourites match with what most people like, you might find your song playing at the restaurant soon!

  12. Tell a cartoon story app

    Every picture has its own story, right? Well, things can be made a lot more interesting if you could portray your life in the form of a comic strip – with the images stored on your phone. The app will need to have a large-ish number of cartoon templates and storyboards, along with effects, filters, emoticons, and of course comic-strip themed captions. Once your comic strip is ready, you can share it directly on Facebook and Twitter. Your life story as a series of comics – now that’s an interesting thought!

  13. App for a cleaner neighborhood

    This app would be best built for the iOS platform, and its target audience would be all responsible citizens who take it on themselves to maintain the cleanliness of their localities. Users shall be able to take snaps of unclean, cluttered, garbage-dumped spots in their neighborhood, and upload the same on the app. Next, they have to create a ‘cleaning project’, along with a pre-specified budget. Once that is done, the local municipal bodies and NGOs will be notified – and the dirty areas will be cleaned by professionals, in exchange of the mentioned fee. There are many people who do not mind spending a bit for getting a healthier, cleaner environment – and for them, an app like this would be ideal.

  14. Rain prediction app

    There is a gamut of weather apps at Apple itunes and Google Play Store. All of them provide weather forecasts (accurately or otherwise!). A rain prediction app would be an upgrade over such existing applications. The app will be created with a strong and updated backend support, and would display the actual number of minutes before rain is expected to arrive – when the mobile device is pointed towards the sky (if no rain is expected within the next 24 hours, a message will be generated for users). Any mobile app company that takes up the challenge of making a rain predictor app will have to make sure about its accuracy. If it functions well, the app can be of great help to everyone.

  15. A ‘No Smoking’ app

    For those who are trying to quit smoking, this app can deliver some extra motivation. When a user lights up a cigarette, (s)he will also have to launch the app, and enter all the details of his/her smoke – right from the cigarette brand, to its length and type (i.e., filtered or non-filtered). The app would track and show the extent of damage having that cigarette is doing to your lungs (in particular), and your health (overall). The data can be shown both numerically and visually. Real-time tracking of the harm that smoking does – if that does not keep you away from the temptations of frequently having a puff, nothing will!


There are plenty of existing apps at the stores (for example, instant voice translator apps for conversations with a foreigner) that can do with some improvement. Apart from the ones mentioned above, 2017 might well see a whole new range of home security, decoration, shopping and educational apps – each with something new on offer. There will be a decided focus on making apps for wearables as well. The ball is now in the court of mobile app agencies across the world to work on new app ideas, and make the overall ‘app economy’ more diverse, more interesting.


Are You Familiar With These 9 API Testing Tools?

Hussain Fakhruddin
Follow me

Hussain Fakhruddin

Hussain Fakhruddin is the founder/CEO of Teknowledge mobile apps company. He heads a large team of app developers, and has overseen the creation of nearly 600 applications. Apart from app development, his interests include reading, traveling and online blogging.
Hussain Fakhruddin
Follow me

Latest posts by Hussain Fakhruddin (see all)

Among the many concerns of API providers, the biggest is related to API quality and performance (as highlighted in a previous post). In a API security webinar conducted by SmartBear and Axway, 56% of the attendees mentioned that security is a ‘very important’ feature in APIs. Rather strangely, only around 12% of the same group of people stated that they had a proper API security testing procedure in place. Apart from security, many other issues can affect the performance of APIs. According to reports, nearly 25% of all API issues remain unresolved after a week – a significant figure considering that 1 out of 3 customers is likely to switch to another provider in such cases. In today’s feature, we will briefly highlight some common types of API testing, before moving on to 9 effective API testing tools:


Types Of API Testing

Before we get any further into this discussion, let’s clear the concept of ‘API Testing’ first. As is the case for any software and mobile applications, testing is all about finding out bugs and inconsistencies in performance, so that they can be resolved quickly, prior to final launch. For testing APIs, custom software is employed to make API calls. The system generates a response, which is recorded and logged. The focus is on ensuring that the API itself, and its associated integrations, are functioning as they are supposed to (and there is consistency across different conditions). Here are the main types of API testing that are performed at organizations:

  • Usability Testing – This is done to check the user-friendliness of new APIs. With ‘the learning curve’ being an important factor in determining the overall API quality, thorough usability testing is vital.
  • Proficiency Testing – What are APIs supposed to do? That’s right, they should enhance the productivity of the web and mobile app developers. As the name suggests, this form of testing is done to find whether an API actually helps developers/end-users.
  • Load Testing – The number of calls that an API has to handle is likely to vary with time. Through systematic load testing, providers can check whether APIs can handle huge call volumes.
  • Security Testing – Arguably, the most important form of API testing. All the security specifications of an API, right from access control and user authentication, to required permissions, are checked through security testing of APIs.
  • Discovery Testing – More commonly known as API documentation testing, this is done to ensure that users have enough guidance in the form of formal documentation.
  • Functionality Testing – The most basic type of API testing. Functionality testing is about finding out whether an API is ‘functioning’ as it is meant to. If not, the root cause(s) are identified and resolved.
  • Reliability Testing – These are the tests performed to determine whether the responses/outputs from APIs are consistent for different projects, in all scenarios.

In addition to the above, Creativity Testing for APIs is also often performed by companies. The purpose for this is determining the extent of customization supported by an API.


Tools For API Testing

Not having access to the required technology/resources, and not delegating the tasks to the correct individual/team are two key reasons behind API testing often remaining incomplete and half-baked. You need to have proper working knowledge of these tools, to make sure that your APIs never fall short on the quality front:


  1. HttpMaster

    Primarily used to test web API calls (i.e., load testing), the HttpMaster tool automates the overall process of web application testing. POST, GET and DELETE are some of the common http methods supported in this tool, along with a fairly large array of validation methods and expressions. API requests can be clubbed into batches with the dynamic parameters of the web development tool, making the testing process easier for developers. In addition to API testing, HttpMaster can be used for website testing and service testing as well.

  2. Apache JMeter

    A Java-based, multi-utility, open-source tool for load testing and functionality testing of the endpoints of Web services APIs. JMeter is increasingly being used to test RESTful APIs as well. The multi-threaded feature of this tool makes it ideal for performing effective, accurate load testing. Multiple protocol types are supported by Apache JMeter (FTP, LDAP, SOAP/REST, HTTP/HTTPS, and more), during performance testing and load testing of APIs.

  3. SoapUI

    One of the most ‘complete’ API testing tools out there at present. From load and regression testing, to compliance and, obviously, functional testing can be done with this software resource. The built-in Groovy support enables API testers to generate complicated validation scripts with ease, while web method requests can be used to directly generate test cases. SoapUI offers cross-platform functionality and serves as a tool for testing both REST APIs and SOAP APIs. Assertions (created with XQuery or XPath) are used to generate the web method results. The test setup in SoapUI can also be altered, as and when required.

  4. DHC

    Created by Restlet, DHC is a widely used Web API testing resource. The tool allows users to seamless integrate the API testing procedure with their Continuous Integration (CI) and/or Continuous Delivery (CD) delivery methods. The built-in graphical user-interface of DHC doubles up as an excellent visual tool for monitoring API calls. A large number of API requests can be bunched together in test scenarios, with the tool having the capability to handle requests of varying complexity. The responses to requests can be analyzed easily too.

  5. Postman

    For manual API testing, Postman – which is basically a Google Chrome plug-in – can be just the perfect tool. Since Postman is, in essence, a high-end HTTP client, it supports practically all forms of modern web API data (for extraction or exploration). The interface of the tool allows testers to write out custom Boolean test scripts, while batches of REST calls can be created and saved (for later execution) too. A big advantage of Postman is that it is not a command-line based tool (unlike, say, CURL), which makes using it considerably easier.

  6. Runscope

    Generally used for checking XML as well as JSON endpoints, Runscope is goes beyond the definition of ‘just another API testing tool’, and simultaneously serves as a ‘traffic inspector’ for APIs as well. It monitors API uptimes on a continuous basis, and notifies users as soon as an API stops working. The third-party metrics integrations supported by Runscope bolster the overall API monitoring process further. API providers can use the tool to create and deploy functional tests, along with accessing private APIs (when required). API traffic can be monitored on a real-time basis through this tool, and issues can be promptly logged and debugged.

  7. Parasoft

    Parasoft is often the go-to testing tool for APIs without graphical user interfaces (GUIs). A vast range of protocols is supported by the Parasoft interface, making the task of specifying automated test scenarios a lot simpler. Scenarios of varying complexities are automated by this tool – across mainframes, databases and even messaging layers. The tests created with Parasoft are typically reusable and scalable, apart from being easy to maintain. The tool is best for performing regression testing of APIs with state-of-the-art validation methods. A high point of Parasoft is that, it lets users create tests without having to actually code.

  8. TestingWhiz

    Yet another code-free API testing tool (it also performs mobile testing, big data testing and database testing). Regression tests for APIs can be easily automated with TestingWhiz, and the tool also offers reliable automated web UI testing services. Practically all the popular browsers are supported (the likes of Firefox, Chrome, IE, Opera, Safari) – enhancing the coverage of tests as well as the convenience of users. More than 290 commands are available for generating modular automation scripts – doing away with the need for coding.

  9. vRest

    For automated testing of RESTful APIs as well as HTTP APIs, vRest is a more than handy online tool. Depending on the precise specifications of each API, documentations are generated by the tool – and it also delivers high-speed validation services for REST APIs. The Mock Server Functionality of vRest, which allows smooth creation of API mocks, also deserves a special mention. Data can be imported from the Swagger API framework without any hassles. vRest also comes with JIRA-Jenkins integration.


TestMaker, HP QTP and Chakram (REST APIs) are some other popular API testing tools and frameworks. The importance of quality in an API cannot be overemphasized – and to maintain performance standards and retain users, using these tools for testing is of paramount importance.

Resources: ,