American Family Insurance Shifts to a Mobile-First Development Strategy with CA API Management

American Family Insurance Shifts to a Mobile-First Development Strategy with CA API Management

Richard Petty

DevOps: API Management and Application Development

American Family Insurance

Manager, API Business Unit

D03X102S

@@Hobicus

#CAWorld

2 © 2015 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD

© 2015 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.

The content provided in this CA World 2015 presentation is intended for informational purposes only and does not form any type

of warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.

Richard Petty and American Family Insurance does not endorse or promote any CA product. These presentation materials and

any discussions during this presentation regarding the use of CA products, including the CA API Management suite are meant

for informational and not endorsement purposes.

For Informational Purposes Only

Terms of this Presentation


Abstract

Advice and insights on using APIs and CA API Management to solve critical integration, delivery and operational challenges. Topics will include cross-origin resource sharing (CORS), concurrent development, monitoring, partner integrations and accelerating delivery through data transformations.

Richard Petty

American Family Insurance

Manager- API Management


Agenda

MOBILE FIRST STRATEGY

MODERN APPLICATION ARCHITECTURE & PRINCIPLES

RECOMMENDATIONS FOR NEW API PROGRAMS

API DESIGN CHALLENGES

API TYPES AND USE CASES

API DOCUMENTATION

1

2

3

4

5

6


Mobile First Strategy

Our customers need mobile friendly solutions

Typical java web applications make supporting mobile difficult– JSP, JDBC, Struts, Spring, etc

– Rendered on the Server

Responsive design techniques can help– Can make applications look “OK” on a mobile browser

– HTML5, Webkit, Hybrid tools such as PhoneGap and Cordova can get close

Native applications need access to data, too

Everything is changing


Modern Application ArchitectureAPIs are the key!

Native Mobile Application

iOS/Android

Controller

View

Services

Mobile First Web Application

AngularJS

Controller

View

Services

API

REST

Services

SOAP

Services

Message

QueuesDatabases


API Principles

The Enterprise API is a Product– Corollary: Governance, Stability, Consistency and Documentation are

KEY

Design APIs for the Enterprise

Expect change – but avoid versioning

Eat your own dog food– Corollary: Build APIs to support the API

On this rock, we will build


API Principles

APIs are the Interface, not the Implementation– Corollary: Do not let the implementation details influence the API

design

– Abstract the implementation details from the consumer

Exploit the API Gateway– Leverage the capabilities of the API gateway where possible

More “fundamental truths”


API Development Challenges

API Design– Tactical and Strategic are often at odds

– Consistency across APIs

– Build new or leverage existing services?

– Ownership

– Governance is the key

– Patterns and “Cookbooks” help too

Perfection in an imperfect world


API Implementation ChallengesDevelopment Tiers

Development

Integration

Performance

Acceptance

Production


API Implementation ChallengesThe concurrent development complexity multiplier

Development

Integration

Performance

Acceptance

Production

Dec 15 Apr 16 Jun 15

Dec 15 Apr 16 Jun 15

Dec 15 Apr 16

Dec 15 Apr 16

Production


API Implementation Challenges

API Gateway “Policies” need to be defined for each Tier, and Branch. – Automated policy deployment across the tiers becomes necessary

– Must externalize tier specific configurations (routes, database connections, credentials, etc.)


API Implementation Challenges

Providing consistent, readable documentation of Enterprise APIs– API Portal provides a good start

– Allows consumers to try the API

– Provides an avenue for support and building a community of consumers

– Does not automate the development of good, solid API documentation

Documentation


Types of APIs

Single Use– APIs implemented for a single application

– Typically exposes a newly built back end service

– Uses the API gateway for Security and CORS processing

– Sometimes grows up to be an Enterprise API

– Documentation and Testing up to solution delivery team


Types of APIs

3rd Party– External Vendor service calls

Can be either inbound or outbound

– Typically Leverages the API gateway for Security, message transformation and content based routing

– Documentation and Testing up to solution delivery team


Enterprise APIs

APIs designed, built, implemented from the ground up for reuse

These are the “API as a product” APIs

Detailed documentation for the API made available via the Developer Portal– Includes online support forum

– Developer/Application Keys

Testing and Support comes from the API team.

The Holy Grail


API Gateway Use Cases

Handling Concurrent Development

Cross Origin Resource Sharing (CORS)

External Vendor Integration

REST API which leverages existing SOAP services

Speed development with mock responses

Route Administration

API Security

A non exhaustive list


Gateway Terminology

Assertion – A rule within the API Gateway

Service – A single API endpoint definition on the API Gateway– Typically made up of a collection of assertions

– Often called a “Policy”

Subroutines– Policy Fragment – A collection of assertions which can be reused across

Services

– Encapsulated Assertion – A wrapped Policy Fragment with defined inputs and outputs. Think of it like a “Function”

– Global Policy – Policy fragment called on every API call

Background Information


Handling Concurrent Development

The API Gateway allows for organizing APIs into folders– Typically folders are used to group APIs

– Typically it is good practice to have the folder structure match the API URL

– /apiname/v1/theapi lives in a folder of the same name

Leverage URL standardization to handle branches– /apiname/v1/01/theapi Branch 01

– /apiname/v1/theapi Production Branch

Leverage Regular Expressions to extract Branch name if needed for routing to proper back end branches

One possible solution


Cross Origin Resource Sharing

Most API calls are made via AJAX.– Since these calls are to a different server than the host application, the

browser identifies these calls as “Cross Site Scripting” attacks

– The CORS specification was built to allow for safe access to external sources

CORS consists of a set of headers which must be handled correctly in order for the request to succeed

Typically also requires the proper processing of the HTTP OPTIONS request during preflight

CORS


Cross Origin Resource Sharing

Request Headers– Origin

– Access-Control-Request-Method

– Access-Control-Request-Headers

Response Headers– Access-Control-Allow-Origin

– Access-Control-Allow-Credentials

– Access-Control-Allow-Headers

– Access-Control-Allow-Methods

– Access-Control-Max-Age

CORS Preflight – HTTP OPTIONS


CORS - Gateway Implementation

Developed Encapsulated Assertions to handle HTTP OPTIONS requests– HTTP OPTIONS does not pass security credentials with the request

– Access-Control-Allow-Methods header value externalized via Admin API

Developed Encapsulated Assertions to handle CORS on the actual request– Set Access-Control-Allow-Origin and Access-Control-Allow-Header

headers

Standardized implementation across all APIs

CORS


External Vendor Integrations

Centralize calls to external vendors through the gateway– Insert security credentials into outbound requests

– Add WS-Security as required by the vendor

– Remove extraneous WS-* headers from outbound request

Inbound calls from external vendors– Manage security via 2-way SSL and CA Siteminder

– Insert internal credentials into outbound request

– Content based routing by inspecting messages and routing to appropriate tier/branch

Some ways to use the gateway


REST to SOAP

API specification is typically REST/JSON

Back end service is SOAP/XML

Use the API Gateway to parse request JSON– JSONPath, JSON Schema, Regular Expressions

Formulate the necessary SOAP message(s) to perform the operation and call the back end SOAP service(s)

Use Regular Expressions and XPATH to extract values from the results and build a JSON response message

Reuse existing SOAP Services


REST to SOAP

Design API independent of the existing SOAP service– Don’t let the existing SOAP implementation drive the definition of a

good, robust API

XML Namespaces and complex schema– Typically namespaces need to be removed before converting XML to

JSON

– Complex responses, especially those with XML attributes do not translate well to JSON

Orchestration across multiple services can push business logic into the API definition

Pitfalls


Smart mock responses

API Designs are typically created up front– Typically developing new back end services takes time

– UI developers want to leverage new API before back end is ready

Template responses allow the API to be implemented as soon as the API Design is complete– With a little extra logic added to the implementation, the template

responses can echo values sent with the request

– With a little more logic you can simulate success/failures

Not quite virtualized services


Route Administration

Service Metadata– Back end resource URIs

– OPTIONS (GET, PUT, POST) responses for CORS

– Credentials to use when calling back end services

– Message Queue Names

Created an API which stores this information in cluster-wide properties based on the name of the service– Developed AngularJS UI to access route administration API

Created Global Policy to prefill this information and make it available on every service call automatically

APIs to manage APIs


API Security

Too many topics to cover here: – Authentication/Authorization mechanisms

– SSL/TLS Certificates

– API Hackability, the good and the bad of AngularJS and APIs

Involve your security team up front– Develop patterns early for securing your APIs

– Enforce those patterns through reviews and governance

Just scratching the surface


API Documentation

Standards and Patterns– When to build a new service? When to leverage an existing service?

– URI naming conventions

– POST, GET, PUT, DELETE = CRUD

– API Implementation details

Headers, MIME Types, Error codes

Result set specific parameters

– Order By, Pagination, Filter

Status Object

Standards and Patterns


Document your API

Introduction – What is this API for?

Getting Started– Links to full API specification

– Link to SoapUI project

Operations– A well decorated WADL file will auto-document these operations on

the API Portal

Request and Response object details– Every field, every object, every structure

Key API documentation


API Portal

The portal provides:– A central place for API documentation

– Support Forums

– Developer Keys

– Rate Limit plans for API consumers

A good start


API Portal - Challenges

Typically you separate service definitions– /billing/v1/accounts

– /billing/v1/payments

– /billing/v1/payment/{id}

Allows for clean separation of code between API operations

API Portal requires ONE service definition– /billing/v1/*

– You’re required to parse the request and build out the API in Gateway policy code

It’s not always easy


New API Program Tips and Tricks

Start with principles and patterns– Consistent API design is key

Implement governance early– Review API designs and implementations against the standards

– Build the governance/reviews into the development process

Plan on refactoring your API definitions a few times– As your knowledge of the API gateway grows, so will the complexity of

your API Gateway policies

Lessons Learned



Avoid Versioning the API– Establish clear guidelines with API Consumers

– APIs only need versioning on the following conditions

The meaning of the data has changed

Radical changes to the object structure

New required fields which are not discoverable by the consumer

– Consider having an API which can tell the consumer what fields are required

– Adding new functionality, expanding object structures, or including new optional parameters does not require a new version

Lessons Learned



Start building deployment automation early in your program– Branched development can proliferate service definitions

– Moving service definitions up development tiers is time consuming and prone to errors

Externalize configuration items wherever possible– Leverage API Gateway cluster properties

– Consider building an Administrative API

Lessons Learned


API Program Tips and Tricks

Get Help– Developing API Principles, Patterns and Standards requires training

– Implementing deployment automation requires specific knowledge of the API Gateway’s available migration tools

CMT (Command Line Migration Tool)

WSMan and RESTMan – APIs provided by the gateway for migration and configuration

Lessons Learned


Recommended Sessions

SESSION # TITLE DATE/TIME

DO3T11S

Business Transformation: Hewlett-Packard Enterprise

View on Going Big with API Management - Application

Transformation, Hybrid Infrastructure and Secure Access

at an Enterprise Scale

11/18/2015 at 3:45 pm

DO3X95S

Technology Primer: Accelerating the Mobile App

Development Process – How to Simplify Building Context

Aware and Reactive Mobile Apps

11/18/2015 at 4:30 pm

DO3X101SBusiness Transformation: Reframing Strategic Advantage

through APIs11/19/2015 at 1:00 pm


Must-See Demos

Unlock the Value of APIs

APIM SaaS

Theater 3

Simplify API Design

CA Live API Creator

Theater 3

Accelerate Mobile DevelopmentMobile App Services

Theater 3

Build Digital Ecosystems

IoT

Theater 3


Follow Conversations At…

Smart Bar

API Management

Theater 3

Tech Talks

API Management

Theater 3


Q & A


For More Information

To learn more, please visit:

http://cainc.to/Nv2VOe

CA World ’15

http://cainc.to/Nv2VOe

http://bit.ly/1wbjjqX