API Part 2 - creating and managing your api
Upcoming SlideShare
Loading in...5
×
 

API Part 2 - creating and managing your api

on

  • 1,211 views

Second part of the API course, this one focus on how to build and deploy your API

Second part of the API course, this one focus on how to build and deploy your API

Statistics

Views

Total Views
1,211
Views on SlideShare
1,209
Embed Views
2

Actions

Likes
3
Downloads
52
Comments
0

2 Embeds 2

http://www.linkedin.com 1
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

API Part 2 - creating and managing your api API Part 2 - creating and managing your api Presentation Transcript

  • Competing In A Digital World Creating and Delivering Your API William El Kaim Global Marketing and Enterprise Strategy - Innovation Team Copyright © 2014 CWT CWT - Copyright © 2011 Image from M6D
  • Disclaimer This presentation is a journey into the digital world through my personal lens. My work as an innovator means I am used to trying, testing and imagining! Most of the content of this tutorial provides from a reduced number of great resources presented at the end Copyright © 2014 CWT 2
  • Plan APIs Impact Your Organization The Rise Of Restful APIs Describing Your Open API Promoting Your Open API Managing your APIs Backend As A Service (BAAS) What About The Human API? Best Practices and Lessons Learned Copyright © 2014 CWT 3
  • APIs Impact Your Organization CWT Company Confidential Copyright © 2014 CWT 4
  • Traditionally, IT Management Controls The Whole Value Chain Of a Company’s Data! Copyright © 2014 CWT 5
  • Whereas Internal Apis Give More Flexibility And Speed Up Internal Processes Copyright © 2014 CWT 6
  • Comcast Case Study Copyright © 2014 CWT 7
  • API Usage Copyright © 2014 CWT 8
  • Accessing Hardware Resources Chef and Puppet Copyright © 2014 CWT 9
  • Voice Over IP and Telephony Copyright © 2014 CWT 10
  • ERP Copyright © 2014 CWT 11
  • API Legal Considerations Like in any business, platform providers should ensure due diligence on the legal side of the API. issues like misuse of the API and data stored in the platform by third party providers and the associated legal ramifications. issues like the contract between the service providers and developers and potential legal wars associated with it. These are some of the legal problems that could spring up while opening up the API for a platform. Copyright © 2014 CWT 12
  • Open API No Copyright US “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical.” EU [... the Court holds that neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression. Accordingly, they do not enjoy copyright protection.] Copyright © 2014 CWT 13
  • The Rise Of Restful APIs CWT Company Confidential Copyright © 2014 CWT 14
  • APIs and Coupling APIs have been used as a mechanism for linking programs since the early days of software. However, API creation and design have significantly changed. Early methods were proprietary and created interdependent coupling among pieces of code and systems. If one side of the coupling required a code change, the other side was affected. Over time, APIs evolved to reduce the interdependency of tightly coupled interfaces, generally lowering the complexity of integration. Source: PWC Copyright © 2014 CWT 15
  • The rise of RESTful APIs Within the last decade, enterprises began to expose APIs to allow external parties to build new functionality Service-oriented architecture (SOA), which gained wide acceptance using web services built on SOAP, has been popular within organizations as a mechanism for sharing information across the enterprise. Today, communication on the web has evolved from the early days of using SOAP standards to using features of RESTful methods, making REST-compliant APIs a major class of web services. However, the use of a REST architecture, along with associated technologies such as JavaScript Object Notation (JSON), is accelerating the development and use of APIs. Source: PWC Copyright © 2014 CWT 16
  • The rise of RESTful APIs Why Now? APIs are becoming the basis for creating digital value chains, including digital indirect channels previously established mainly by software companies and purely webbased companies. One big reason behind the successful adoption of RESTful APIs is developers’ ability to build modular capabilities with lightweight interfaces that don’t require heavy integration. “RESTful interfaces create a level of simplicity that didn’t exist previously, and simplicity always speeds things up, making integrations cost-effective,” says John Musser, founder of ProgrammableWeb. Key tools for participating in the digital economy are now: A relatively new style of APIs, called representational state transfer (RESTful) APIs, and Solutions to manage them, called API management platforms Source: PWC Copyright © 2014 CWT 17
  • The rise of RESTful APIs Also Called Web API Web API is described as: “A set of Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.” Hence a Web API can be defined without the technical specifics as: “An interface to a software component that can be invoked at a distance over a communications network using standards based technologies.” Copyright © 2014 CWT 18
  • The rise of RESTful APIs What is REST? REST stands for representational state transfer, meaning that a client communicates with a server and not directly with the source of information on that server. This transfer is done through representations of the state of that resource. The REST architectural style for distributed systems was developed around 2000, and it is patterned after the HTTP/1.1 Protocol. In RESTful designs, the client does not need to know about the implementation on the server. The server is free to store data as it likes, and the client can store the same information differently. This loose coupling means that as long as the interface is stable, the implementation on the client or the server can independently change. Copyright © 2014 CWT 19
  • REST architectural style is Based on Six Principles Client/server loose coupling A clean separation of duty exists between client and server. The type of data storage does not matter to the client, and the client interface or client state does not matter to the server. With a stable interface, the client and server may be developed and replaced independently of each other. Stateless The interface that dictates how the client and server interact does not allow client states to be stored on the server. Information about client states is embedded in the messages the clients send to servers. Cacheable Clients can have the ability (and must let the server know whether they do or not) to temporarily store data received from the server. Copyright © 2014 CWT 20
  • REST architectural style is Based on Six Principles Layering Servers do not know whether there are layers of abstraction between themselves and the end client For example, whether they are passed through multiple security policies, APIs, and so forth. Code on demand Servers are able to temporarily send custom functions as executable code to clients for them to execute. Uniform interface Servers and clients can interact, change, and be modified independently as long as the interface that binds them remains the same. Source: PWC Copyright © 2014 CWT 21
  • From REST to Restful … An API implemented using the preceding principles of REST and using standard HTTP communications protocols is a RESTful API, sometimes called a RESTful web service Like any resource on the web, the RESTful API will need a Uniform Resource Identifier (URI), such as an http:// address. RESTful API developers are increasingly using REST in conjunction with JSON Source: PWC Copyright © 2014 CWT 22
  • REST and RESTful Synthesis Copyright © 2014 CWT 23
  • Entering JSON JSON is a resource-based data transfer mechanism, to further simplify the process of communication between the information seeker (the client), and the system containing the information to be consumed (the server). JSON is derived from the JavaScript scripting language, which is widely used in web browsers to enhance interfaces and build dynamic websites. Like REST, JSON is noted for its simplicity and usability With JSON, data is sent in plain text, which makes it easy to read and understand. Because so many web client programs are written in JavaScript, JSON data arrives ready to be consumed without needing further manipulation. At the same time, JSON lacks display capabilities and has a limited amount of development tool support. Source: PWC Copyright © 2014 CWT 24
  • RESTful Architecture and REST Languages Copyright © 2014 CWT 25
  • SOAP vs. REST For many enterprises, the path to web services begins with the adoption of a service-oriented architecture (SOA), which uses SOAP as a method for exchanging information. In today’s web service world, both SOAP and REST are used as methods of communication. There are several factors behind the popularity of REST when contrasted with SOAP. REST uses simple HTTP and therefore standard commands—such as GET, PUT, POST, and DELETE—to coordinate communication between clients and servers. SOAP has no widely accepted methods corresponding to GET, PUT, POST, and DELETE, which leaves developers free to define their own semantics. But the result can be complex, proprietary mechanisms to connect components. Source: PWC Copyright © 2014 CWT 26
  • SOAP vs. REST Familiarity Since REST is closely related to web design, web developers do not face a steep learning curve. REST is also language and platform agnostic. SOAP requires a significant skill set in SOA-specific development and delivery tools. Efficient with bandwidth. The use of the existing web infrastructure eliminates the need for an additional messaging layer in RESTful APIs. Coupled with the fact that REST uses those short request and response sequences, these APIs consume considerably less bandwidth than SOAP-based APIs. Scalability. With simpler component implementations and reduced complexity in the connection semantics, RESTful services can scale—as evident from several services that register more than 1 billion API calls each month. Copyright © 2014 CWT 27
  • SOAP vs. REST Source: PWC Copyright © 2014 CWT 28
  • SOAP vs. REST … Copyright © 2014 CWT 29
  • API Protocols and Styles Copyright © 2014 CWT 30
  • JSON vs. HTML Copyright © 2014 CWT 31
  • Percentage of REST API Supporting JSON Copyright © 2014 CWT 32
  • API Versioning Copyright © 2014 CWT 33
  • API Security Baseline Copyright © 2014 CWT 34
  • Finding your Hackathons Some Dedicated sites: Hackerleague.org: Power Hackathons for companies trusting Hacker League to handle hackathon planning and organization. Hackathon.io: Join Hackathon.Io To Discover Hackathons Or Create Your Own Hackathonhero.com: Directory listing of Hackatons Try a Google News Search of past hackathon winners. You an also do it yourself at home: Choos an API randomly (via API Randomizer, code here) And start coding. Learn how to code with codeAcademy API Track Copyright © 2014 CWT 35
  • http://www.codecademy.com/tracks/apis Copyright © 2014 CWT 36
  • Join a Developer Community https://coderwall.com/ Copyright © 2014 CWT 37
  • Describing Your Open API CWT Company Confidential Copyright © 2014 CWT 38
  • Richardson Maturity Model Level 0: HTTP as a transport system for remote interactions Level 1: Resources Level 2: HTTP Verbs Level 3: Hypermedia Controls Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 39
  • Richardson Maturity Model Level 0: HTTP As A Transport System The starting point for the model is using HTTP as a transport system for remote interactions, but without using any of the mechanisms of the web. Essentially what you are doing here is using HTTP as a tunneling mechanism for your own remote interaction mechanism, usually based on Remote Procedure Invocation. RPC style system. It's simple as it's just slinging plain old XML (POX) back and forth. If you use SOAP or XML-RPC it's basically the same mechanism, the only difference is that you wrap the XML messages in some kind of envelope. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 40
  • Richardson Maturity Model Level 1 - Resources The first step towards the Glory of Rest is to introduce resources. So now rather than making all our requests to a singular service endpoint, we now start talking to individual resources. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 41
  • Richardson Maturity Model Level 2 - HTTP Verbs Using the HTTP verbs as closely as possible to how they are used in HTTP itself. Use of GET for a request like this is crucial. HTTP defines GET as a safe operation, that is it doesn't make any significant changes to the state of anything. This allows us to invoke GETs safely any number of times in any order and get the same results each time. n important consequence of this is that it allows any participant in the routing of requests to use caching, which is a key element in making the web perform as well as it does. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 42
  • Introduction to HATEOAS HATEOAS is a constraint of REST. The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. In a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL). RESTful service can be described as well to be available for the client code-generation, RSDL (RESTful Service Description Language) using dynamic metadata collection to achieve this goal. The HATEOAS constraint serves to decouple client and server in a way that allows the server to evolve functionality independently. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 43
  • Richardson Maturity Model Level 3 - Hypermedia Controls The final level introduces HATEOAS (Hypertext As The Engine Of Application State). It addresses the question of how to get from a list open slots to knowing what to do to book an appointment. Hypermedia controls tell us what we can do next, and the URI of the resource we need to manipulate to do it. Rather than us having to know where to post our appointment request, the hypermedia controls in the response tell us how to do it. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 44
  • Richardson Maturity Model Level 3 - Hypermedia Controls One obvious benefit of hypermedia controls is that it allows the server to change its URI scheme without breaking clients. A further benefit is that it helps client developers explore the protocol. The links give client developers a hint as to what may be possible next. Similarly it allows the server team to advertise new capabilities by putting new links in the responses. If the client developers are keeping an eye out for unknown links these links can be a trigger for further exploration. There's no absolute standard as to how to represent hypermedia controls. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 45
  • Using Hypermedia-Style Messages to Build Flexible, Durable APIs With a Hypermedia API, the API will use a registered media type such as HAL or Collection-JSON, providing a common framework for developers to communicate with the API Reducing the unknowns in API integration. Two major options for a hypermedia type. Use an existing type: XHTML, Collection+JSON, HAL, Siren Build your own Two paths: Make a custom type, or use the profile link relation. If you'd like to make a custom type, read Building Hypermedia APIs in HTML5 and Node. Building a custom type is just as much art as science. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 46
  • Richardson Maturity Model Synthesis Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources. Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation. Level 3 introduces discoverability, providing a way of making a protocol more self-documenting. Source: http://martinfowler.com/articles/richardsonMaturityModel.html Copyright © 2014 CWT 47
  • A new Initiative API Commons Why? APIs are transforming the web in radical new ways are clearly leading a great deal of innovation and value This rapid growth however also brings with potentially huge costs namely the need to create client (and server) code for potentially hundreds of thousands or millions of unique, slightly different APIs. While there are some solutions to help reduce this cost (automated code generation, or more flexible intelligent client code) the unlikely to make much of a dent in the overall problem in the short and mid term. A further problem is that, despite recent copyright victories, the reuse of API interfaces (the definitions of them / data models / call partners etc.) remain a legal grey area and reuse of interface patterns may result in legal risks. Copyright © 2014 CWT 48
  • What If API Definitions Were Actually Explicitly Open And Shareable? API Commons proposes to encourage API designers to declare APIs the produce to be "In the Commons" much the way creative work can be licensed under Creative Commons or code can be open sourced. Initiative from Kin Lane the API Evangelist The objective of doing this is to: Make it explicit when an API in whole or part could be re-used Over time build up a valuable set of reusable API interface resources The most popular of which may in turn encourage shared development of shared client (or server) code Remove legal risk from API Interface design reuse Dedicated web site: http://apicommons.org/ Copyright © 2014 CWT 49
  • Example Copyright © 2014 CWT 50
  • Copyright © 2014 CWT 51
  • Copyright © 2014 CWT 52
  • Describing your API via Web API Languages Copyright © 2014 CWT 53
  • Web Api Languages Can describe Web APIs XML or JSON driven representations proper HTTP methods usage markup languages (XML, JSON, YAML, MarkDown) Can generate code client SDKs server skeleton Key Examples Swagger RAML (RESTful API modeling language) Google API Discover Service Api Blueprint Copyright © 2014 CWT 54
  • Swagger Tool Copyright © 2014 CWT 55
  • In The Meantime, You Must Register in Each API Yellow Page Service! Programmable Web ApiHUb The right API Mashape Find Web API Api for That Exicon API directory apis.io Copyright © 2014 CWT 56
  • Promoting Your Open API CWT Company Confidential Copyright © 2014 CWT 57
  • Open API Ecosystem Copyright © 2014 CWT 58
  • Promoting Your Open API Copyright © 2014 CWT 59
  • What’s Needed? Copyright © 2014 CWT 60
  • DX: Developer Experience The New Pre-requisite For Success Developer Experience is to developers what User Experience (UX) is to users. Refers to developer experiences integrating with an API, from the front-end, portal and key retrieval experience, down to back-end data integration. Resources developerexperience.org see also developer-support-handbook.appspot.com Developer Experience: The UX of APIs from Jeremiah Lee Mashery DX Certified API Pamela Fox (Youtube and Slideshare presentation) Copyright © 2014 CWT 61
  • Dedicated Portal Copyright © 2014 CWT 62
  • Documentation Copyright © 2014 CWT 63
  • Code Samples & SDK Copyright © 2014 CWT 64
  • Tools Copyright © 2014 CWT 65
  • Marketplace Copyright © 2014 CWT 66
  • Hackathons In any platform, APIs greatly simplify the life of developers by making it easy to access the functionality of the platform. Instead of developing everything from the scratch, they could tap the APIs and access the functionality easily speeds up the platform access makes the platform highly extensible leading to a rich feature set helps co-opt with other service providers helps in integration and interoperability helps in better management of platform security offers an easy option to handle analytics even helps in ensuring compliance Copyright © 2014 CWT 67
  • Hackathons A hackathon (also known as a hack day, hackfest or codefest) is an event in which computer programmers and others involved in software development collaborate intensively on software projects. Hackathons typically last between a day and a week. Some hackathons are intended simply for educational or social purposes (creating community of users), although in many cases the goal is to create usable software. Hackathons tend to have a specific focus, which can include the programming language used, the operating system, an application, an API. Example http://apihackday.com/ Copyright © 2014 CWT 68
  • Meetup The noun Regular (or more spontaneous) face-to-face meetings of Wikipedians take place in cities around the world. The service Meetup is an online social networking portal that facilitates offline group meetings in various localities around the world. Meetup allows members to find and join groups unified by a common interest, such as politics, books, games, movies, health, pets, careers or hobbies. Users enter their postal code or their city and the topic they want to meet about, and the website helps them arrange a place and time to meet. Topic listings are also available for users who only enter a location. Meetup receives revenue by charging Organizer Dues to administrators of groups, currently at $12 to $19 per month depending on the payment plan. http://www.meetup.com/ Copyright © 2014 CWT 69
  • Copyright © 2014 CWT 70
  • Conversations Use standard and dedicated to developer collaboration and social tools to ease discussions with developer GitHub GitHub is a web-based hosting service for software development projects. Originally born as a project to simplify sharing code, GitHub has grown into the largest code host in the world. GitHub offers both commercial plans and free accounts for open source projects. Geeklist Geekli.st is an achievement-based social portfolio builder for developers where they can communicate with colleagues and employers and build credibility in the workplace. Stackoverflow Stack Overflow is a free programming Q & A site. Stack Overflow is collaboratively built and maintained by its members. Copyright © 2014 CWT 71
  • Widgets, Mini Apps, And Enterprise Mashups. itDuzzit makes it easy to create alerts, widgets, mini apps, and enterprise mashups. Leverage content from popular web sites and services, configure intelligent apps, and push cloud content to any web site, platform, social media, email, SMS, and phone. Copyright © 2014 CWT 72
  • Managing Your API CWT Company Confidential Copyright © 2014 CWT 73
  • API Delivery Copyright © 2014 CWT 74
  • API Delivery Copyright © 2014 CWT 75
  • API Management Is Now Required! Copyright © 2014 CWT 76
  • Managing API Copyright © 2014 CWT 77
  • Managing API Source: PWC Copyright © 2014 CWT 78
  • API Mgt – Facilitate API Adoption, Documentation and Management As organizations become determined to publish APIs as part of their Internet infrastructure and application strategies, they learn that simply putting an API up for use by others is not entirely too complex. However, they also discover that publishing a reliable, secure, enterprise-grade API to a controlled audience with high levels of performance that have the ability to scale with adoption can be quite a serious undertaking. These kinds of requirements are why the API Management space has emerged to the forefront. Need Solutions for publishing APIs, creating and managing a developer community and for scalable routing API traffic Copyright © 2014 CWT 79
  • API Mgt – Facilitate API Adoption, Documentation and Management Why Now (Spring 2013)? First, the proliferation of SaaS applications and integration requirements has contributed significantly to the interest in API Management. Second, legacy applications moving to the Cloud and the need to pass messages and data between these applications Explosion in mobile devices, tablets, other smart devices, and apps have been major factors. Couple of large acquisitions and increasing investments occurring in the space. Many SOA (Service Oriented Architecture) and other infrastructure vendors have re-invented themselves as API Mgt solutions. Copyright © 2014 CWT 80
  • API Mgt – Two Approaches Proxy Model API Management vendor requires you to provide them with an API endpoint address exposed on the Internet. In other words, you must already have an existing, functional API in place and in a production setting that the API Management vendor will then "wrap" with their own version of the API. Wrapping your API provides the vendor the ability to provide user management and authentication, report usage statistics, and provide other features such as support for multiple protocols like SOAP, REST, and JSON. Copyright © 2014 CWT 81
  • API Mgt – Two Approaches Proxy Model Drawbacks Proxy model still requires you to manage the infrastructure and the software and data behind your API. This includes the unpredictable cost and investment required to scale upon increases in adoption. You must also build in the ability to fail-over when necessary (such as server or database failures), ensure performance and reliability, and essentially mirror the infrastructure requirements of the API Management vendor. This approach also increases the potential points of failure, as both you and your API Management vendor must have consistent, high-performance and reliable uptime numbers simultaneously. This can also be an additional challenge, because if either one of you experience a hiccup or an unsupportable spike in traffic, you are essentially "down". Copyright © 2014 CWT 82
  • API Mgt – Two Approaches Fully-hosted API Model Provide the data, software, or other asset that will be expressed as an API and available to your constituents, and the API Management vendor deploys all of it within their own infrastructure, allowing you to remotely manage and administrate access and availability to that API. This includes all of the user management, reporting and other features that you would receive in the proxy model. Scalability, multi-tenancy, performance, reliability, ongoing monitoring, and security are all abstracted away from you. This also means you don't have to have a team of API infrastructure experts available on your staff to monitor and manage the ongoing usage of your APIs. This is a dramatically simpler approach. Copyright © 2014 CWT 83
  • API Mgt – Two Approaches Fully-hosted API Model While most API Management vendors handle one scenario or the other, some like StrikeIron handles both WebShell : http://webshell.io/ Apigee : http://apigee.com/ and chrome console Mashery http://www.mashery.com/ 3scale : http://3scale.net/ ApiPhany : http://apiphany.com/ Apiary.io : http://apiary.io/ Strikeiron: http://www.strikeiron.com/ Intel ExpressWay: http://cloudsecurity.intel.com/api-management ApiSpark: http://apispark.com/ Copyright © 2014 CWT 84
  • API Mgt – Two Approaches Open source Solution WSO2 API Manager http://wso2.com/products/api-manager Swagger Enables developers to describe the API message, produce API schema documentations, and simplify connecting clients to APIs. Copyright © 2014 CWT 85
  • API Monitoring Developers want to build on the services they provide and the APIs are entirely reliable. Stormpath provides authentication and user management for developers. PagerDuty is a service that offers IT monitoring tools through alerts via SMS, phone, email, iOS or Android. Runscope offers a service for monitoring API traffic. Copyright © 2014 CWT 86
  • Backend As A Service (BAAS) Copyright © 2014 CWT 87
  • Backend As A Service (BAAS) The interactions between humans and machines creates a new set of relationships that we are just beginning to understand. We are becoming more machine-like, which changes the way we co-exist with each other. Data, once impeded, now flows in countless ways between people, machines and the infinite abstractions that force us to re-examine everything in our lives. For example, our phones can open doors and give us directions. Roads and bridges are as much nodes for transmitting data as a server cluster. And the connector is the API, which increasingly serves as the communication between machines, people and things. Source: Techcrunch Copyright © 2014 CWT 88
  • Backend As A Service (BAAS) APIs have spread like paths across an infinite online landscape, transmitting data between apps and in the process creating new ways to live and work. And now APIs are connecting our bodies into systems that store and analyze our data for us to help better monitor the way we manage our own bodies. But APIs are not smart. They are dumb connectors. What we see emerging is a deeper context about APIs. Software is abstracting the infrastructure and the APIs are consuming the data that the software serves. The startups that succeed will treat their APIs like crown jewels. Their APIs will always work, their documentation will be kept updated and they will have people to support it. Source: Techcrunch Copyright © 2014 CWT 89
  • Backend As A Service (BAAS) The cornerstone of this new generation of providers comes from the ability to abstract data and connect APIs through everything from mobile apps to wearable devices. Their success will depend on how well they manage the services they both consume and provide. BaaS is an approach for providing web and mobile app developers with a way to connect their applications to backend cloud storage and processing while also providing common features such as user management, push notifications, social networking integration, and other features that mobile users demand from their apps these days. Copyright © 2014 CWT 90
  • Backend As A Service (BAAS) Firebase, for example, offers a real-time service for managing apps that orchestrates back-end tasks. Wibidata: has developed a framework for companies to develop services that stores the user’s data across multiple dimensions Other Examples Apigee App Services: http://apigee.com/docs/app_services Proxomo: http://www.proxomo.com/ IFFT: https://ifttt.com/login Kinvey : http://www.kinvey.com/ Emergent One : http://www.emergentone.com/ APISpark : http://apispark.com/ Anypresence: http://www.anypresence.com/ Copyright © 2014 CWT 91
  • What About The Human API? CWT Company Confidential Copyright © 2014 CWT 92
  • The Human API = You Wearables are already causing a rethinking of the boundaries of the body and materials. In her TED talk, Lucy McRae demonstrated some of the work Philips Electronics is researching and coined the term “maybe tech” for technologies that are not purely off or on the body and have the effect of blurring the boundaries of the body. She gave the example of electronic tattoos that can conduct electricity and redefine the skin. In this way we can see how the body is becoming a platform or an API as nanotechnologies and computing converge in interesting ways. Copyright © 2014 CWT 93
  • The Human API = You The idea coined by Loic Le Meur and Brian Solis at LeWeb 2013 Who we are, who we know, what we experience and do are important layers in the Internet of Things we do in fact become part of the “machine” API Interface for programmers to develop upon a common platform where software can communicate with other software objects and also devices. The Human API represents an opportunity for relationships and technology to be linked by an open source platform…you. Sets the stage for devices to not only talk to one another, but also talk to us and affect how we process and adapt information to influence how we go through life every day. Copyright © 2014 CWT 94
  • The Human API = You Products such as Fitbit and also Nike’s FuelBand build upon the Human API by collecting the digital breadcrumbs of users and assembling them in a way that makes sense of daily activity and validates progress These devices, the data they collect and present, and the social relationships linked by publishing this information in social channels drives the ongoing pursuit of goals, and brings people together to help one another live better. As these devices are connected socially, experiences become the epicenter of engagement and encouragement, inspiring people and networks of people through extended relationships along the way. Imagine if they could also talk to one another…across devices and also across the various contexts of usage, personal, professional, medical, etc. Copyright © 2014 CWT 95
  • Source: PWC Copyright © 2014 CWT 96
  • The Human API = You The Human API opens up tremendous opportunities to develop devices, apps, and experiences that connect information, people, and aspirations to change behavior….on a common platform. This form of human interface design introduces the potential to create harmony in a world of digital chaos making sense of noise and information overload to accomplish tangible goals or help people see or do things they didn’t or couldn’t before. In the process, we strengthen on our connections around common goals and interests. New company just created … http://humanapi.co/ Copyright © 2014 CWT 97
  • Human API Will Power Cyborg 1.0! Humans as batteries Shoes in development can collect energy from a tiny generator inserted into the soles and a wearable vest can power medical sensors to check high blood pressure and other symptoms that could be dispatched wirelessly back to a doctor or hospital. Human organs could help power devices like a pumping heart driving a pacemaker or knee brackets replacing a soldier’s battery packs by harvesting energy from his movement. Princeton University engineers developed a small wearable chip can capture the energy created by our natural movements to juice small gadgets like a smartphone and other device. Copyright © 2014 CWT 98
  • Human API http://humanapi.co/ Copyright © 2014 CWT 99
  • Best Practices and Lessons Learned CWT Company Confidential Copyright © 2014 CWT 100
  • API … Greatly simplify the life of developers by making it easy to access the functionality of the platform. Instead of developing everything from the scratch, they could tap the APIs and access the functionality easily Speeds up the platform access Makes the platform highly extensible leading to a rich feature set Helps co-opt with other service providers Helps in integration and interoperability Helps in better management of platform security Offers an easy option to handle analytics Even helps in ensuring compliance Copyright © 2014 CWT 101
  • Five Keys To Great API Copyright © 2014 CWT 102
  • Dos & Don’ts Tips To Avoid Pitfalls Dos Don’ts ① API first, Mobile second, Web third ① API as a “side project” ② Do your homework (Who, What, How) ② Neglect developers ③ Start “small” in terms of functionalities (you can always add but you can never remove) ③ Bad documentation (or inexistent) ④ Provide a compelling value proposition to drive adoption and grow your API ecosystem ⑤ Remain flexible to evolve with the needs of your user base ④ Bad sample code/examples (or inexistent) ① No or unclear Terms & Conditions Copyright © 2014 CWT 103
  • Dos & Don’ts Tips To Avoid Pitfalls Define revenue value chain Deploy "sense and respond" and innovation toolkits rather than applications with fixed functionality Propose several business models Adapted for multiple distribution channels Think DATA (Stop thinking Application/IT product) Adopt a flow based vision where real time data is valorised Implement Open API Invest on Business Analysis for finding the most valuable travel services to offer /build. Enhance User Experience Let users select their best in class solutions for each delivery channel Copyright © 2014 CWT 104
  • Dos & Don’ts Tips To Avoid Pitfalls Realizing that developers are your channel Provide them the right resources GitHub, StackOverflow, etc. Organise Hackathons Being “recombinant” and easily mixed Unlocking your legacy data into open APIs Driving new data into your system via open APIs Supporting your application ecosystem Copyright © 2014 CWT 105
  • Be Remixable So That Your API Is Recombinant! REST first, everything else second Nothing weird: straight XML, straight JSON Keep responses small Keep calls granular No custom security schemes: use OAuth Don’t make the developer deal with PCI-compliance Sample code wins every time You’ll get it wrong the first time – so listen well Copyright © 2014 CWT 106
  • Never Forget !!! Copyright © 2014 CWT 107
  • The great list of resources used to build this presentation Copyright © 2014 CWT 108
  • This Presentation Was Built From Great Presentations and Resources 3scale “What is an API?” (Download PDF). “The API Economy: API Provider Perspective”, Steven Willmott, EIC 2012/ Munich, Germany (Slideshare) “APIs for Biz Dev 2.0: Which Business Model?”, Guillaume Balas (Slideshare) “Winning in the API Economy. Using Software and APIs to Transform your Business, …” (Download) “How APIs are changing Application Development”, Steven Willmott (Slideshare) “The API- & APP-ification of the Web”, Steven Willmott (Slideshare) API Evangelist Roundup of 20 API Service Providers in 2012 If you build it they will come (2011) Copyright © 2014 CWT 109
  • This Presentation Was Built From Great Presentations and Resources API Commons “Bringing api design-out-of-the-shadows-and-into-the-commons” , Kim Lane (Html) “Towards an API Commons”, Kin Lane and Steven Willmott, (Slideshare) Apigee Sam Ramji presentations channel – SlideShare White Paper:” Web API Design - Crafting Interfaces that Developers Love”, Brian Mulloy (Download) FaberNovel “Six reasons why API are reshaping your business”, November 2012 (SlideShare) “Why Should I Care About APIs”, December 2013 (SlideShare) Copyright © 2014 CWT 110
  • This Presentation Was Built From Great Presentations and Resources Layer7 “Webinar: Business ROI for APIs”, March 14th, 2013 (Slideshare) “Be My API: How to implement an API strategy …”, Mike Amundsen (Slideshare, YouTube) ProgrammableWeb “Open APIs: What’s HOT, What’s NOT”, John Musser (Slideshare) “API Business Model, 20 models in 20 minutes”, John Musser, API Strategy Conference, 2013 (Slideshare) “What Makes a Great Open API?”, John Musser (Slideshare) Adam Duvander Keynote at TNW2012 (Youtube) RESTLET “Web APIs, the new language frontier”, Jérôme LOUVEL, December 2013 (Slideshare) Copyright © 2014 CWT 111
  • Linkedin http://fr.linkedin.com/in/williamelkaim Blog http://www.reimagine.fr/ Twitter http://www.twitter.com/welkaim Travel 2.0 http://www.netvibes.com/travl20 Contact: welkaim@carlsonwagonlit.com 112