API Design for Mobile Applications · API Design for Mobile Applications Murali Natarajan/John Mutter Mobile Architecture –Apple CoC. ... virtual and normalized representation of

Think 2018 / DOC ID / March 22, 2018 / © 2018 IBM Corporation

API Design for Mobile ApplicationsMurali Natarajan/John MutterMobile Architecture – Apple CoC

Notices and disclaimers

2Think 2018 / DOC ID / March 22, 2018 / © 2018 IBM Corporation

© 2018 International Business Machines Corporation. No part of this document may be reproduced or transmitted in any form without written permission from IBM.U.S. Government Users Restricted Rights — use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. This document is distributed “as is” without any warranty, either express or implied. In no event, shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted per the terms and conditions of the agreements under which they are provided.IBM products are manufactured from new parts or new and used parts. In some cases, a product may not be new and may have been previously installed. Regardless, our warranty terms apply.”Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.

Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how thosecustomers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary.References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business.Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer follows any law.

Notices and disclaimerscontinued


Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products about this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a purpose.The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right.

IBM, the IBM logo, ibm.com and [names of other referenced IBM products and services used in the presentation] are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml..

http://www.ibm.com/legal/copytrade.shtml

Contents


Types of API designs 06App-design based API model 07Canonical API model 08Micro-services based model 09API design guidelines 10A hybrid approach 11Closing guidelines 12

“Design is a plan for arranging elements in such a way as best to accomplish a particular purpose.”

Charles EamesThe Information Machine, 1964

In this presentation, we explore the best practices to consider while designing the backend apis for mobile apps


Types of API designs


§ App design driven

§ Canonical apis

§ Microservices

§ A hybrid approach

App-design based API model


• App design drives the app data model which in turn drives the apis needed

• Api design tightly coupled to screen design and its fields –response structure is custom and could be complex

• Api design cannot start until screens and the app data model are designed

• If a different channel uses (e.g. Web) a different design for the same screen, the api designed for Mobile may or may not fit –i.e. a variant of the same api for the other channel is often created

• Screen design changes – i.e. addition of new and/or removal of existing fields - leads to backend api redesigns

• Might be suited if the number of apps is just 1 or 2 and there are no other channel apps with similar functionalities.

Canonical API model


• Approach based on a canonical business data model that is a virtual and normalized representation of the enterprise data

• APIs are simple http operations on the normalized data entities in the canonical business data model

• Canonical data model will map to actual data from the underlying business systems using some integration solution

• App data model is often independent of the canonical data model; canonical data model and api designs can occur independent of the app development cycle

• Apps use a combination of the required apis to obtain data and processing logic to populate their screens

• Screen design changes have no impact since the apis are decoupled from the consuming apps

• Apps may become chatty in some use contexts resulting in performance concerns

Micro-services based model


• Makes use of micro services apis to the backend

• Very granular and purpose oriented

• Backend data model is not relevant

• Apps use multiple calls to gather and compose data for the UI

• Could become chatty depending on the use context

API design guidelines


• Is there a requirement to continually build multiple different functional apps on multiple platforms (android, iOS, Windows) and on multiple channels for your business?

Ø Canonical data model based apis offer a solution that can be consumed by all apps

Ø Creating a Micro services model for the backend to service multiple apps

• Is there a requirement to be able to work with multiple tools providing similar services that complement each other? For example, an app may tap into more than one Analytics tool or may want to switch easily from one to another type of Analytics tool withoutmaking too much coding changes in the app. Using a centralized analytics data model for the backend with a set of generic apisthereof, the app can work with them without tied to a specific analytics tool. Another example is content management systems. Ifthe app is required to switch seamlessly among different content management solutions in the backend, a canonical api solution might be appropriate

• Is this a stable one-off app or a very specific purpose app with unique data needs? App design driven apis might be a good approach to keep the apis simple as well as intuitive

A hybrid approach is more practical


• Experience has shown that usually there is no clear cut answer to one or the other api approach to take

• Key considerations are driven by the app performance NFRs required for its various use cases

• Goal is to minimize the number of backend api calls while at the same time minimize the impact on the apis due to any potential app design and data model changes

• Where possible, fetch data ahead of time and cache any static data locally. This can help where multiple api calls are required to render a UI screen

Closing guidelines


• Evaluate and decide the best approach. Conducting client workshops early on will help decide how to decide on the api design approach

• Start the api design ahead of app development time if canonical apis will be used.

• If micro-services are used, evaluate the existing services for potential reuse and create new ones as needed

• Resist the temptation to look at the screen design to decide on the design of the apis for the screen fields. Think of the enterprise-wide app ecosystem instead of jumping to provide a one-off solution for this app

• Implementing virtual data model and the apis thereof and/or micro services have middle layer architecture implications. Factor them into consideration before treading down this path

• Validate and refine the api designs/micro-services to come up with best designs as to serve up the apps using minimal api calls

Thank you


Murali NatarajanSr. Mobile Architect – Apple+IBM program—[email protected]

mailto:[email protected]


Documents

API Design for Mobile Applications · API Design for Mobile Applications Murali Natarajan/John Mutter Mobile Architecture –Apple CoC. ... virtual and normalized representation of