api part 2 - creating and managing your api

- Copyright © 2011 CWT Copyright © 2014 CWT Image from M6D

Creating and Delivering Your API

Competing In A Digital World

William El Kaim Global Marketing and Enterprise Strategy - Innovation Team

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


APIs Impact Your Organization

CWT Company Confidential


Traditionally, IT Management Controls The Whole Value Chain Of a Company’s Data!


Whereas Internal Apis Give More Flexibility And Speed Up Internal Processes


Comcast Case Study


API Usage


Accessing Hardware Resources

Chef and Puppet


http://www.opscode.com/chef/

https://puppetlabs.com/solutions/configuration-management/

Voice Over IP and Telephony


ERP


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.


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.]


The Rise Of Restful APIs



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


http://www.pwc.com/us/en/technology-forecast/2012/issue2/features/feature-consumerization-apis.jhtml

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 web-based 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



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.”


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.


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.


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.



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



REST and RESTful Synthesis


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



RESTful Architecture and REST Languages


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.



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.


SOAP vs. REST



SOAP vs. REST …


API Protocols and Styles


JSON vs. HTML


Percentage of REST API Supporting JSON


API Versioning


API Security Baseline


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


https://www.hackerleague.org/

http://www.hackathon.io/

http://hackathonhero.com/

http://apirandomizer.com/

https://github.com/mbernier/apirandomizer

http://www.codecademy.com/tracks/apis



Join a Developer Community

Copyright © 2014 CWT 37 https://coderwall.com/

https://coderwall.com/

Describing Your Open API



Richardson Maturity Model

Level 0: HTTP as a transport system for remote interactions

Level 1: Resources

Level 2: HTTP Verbs

Level 3: Hypermedia Controls

Copyright © 2014 CWT 39 Source: http://martinfowler.com/articles/richardsonMaturityModel.html

http://martinfowler.com/articles/richardsonMaturityModel.html

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

http://www.eaipatterns.com/EncapsulatedSynchronousIntegration.html


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.




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.




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.




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.



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.



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.



http://stateless.co/hal_specification.html

http://amundsen.com/media-types/collection/



http://www.w3.org/TR/xhtml1/

http://www.amundsen.com/media-types/collection/

http://stateless.co/hal_specification.html

https://github.com/kevinswiber/siren

http://www.amazon.com/Building-Hypermedia-APIs-HTML5-Node/dp/1449306578

http://www.amazon.com/Building-Hypermedia-APIs-HTML5-Node/dp/1449306578


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.




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.


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/


http://apievangelist.com/

http://apicommons.org/

Example


Describing your API via Web API Languages


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


http://developers.helloreverb.com/swagger/

http://raml.org/

http://raml.org/

http://raml.org/

http://raml.org/

http://raml.org/

http://raml.org/

https://developers.google.com/discovery/




http://apiblueprint.org/



Swagger Tool


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


http://www.programmableweb.com/

http://apihub.com/

http://www.therightapi.com/discover

https://www.mashape.com/

http://www.webapifinder.com/

http://www.apiforthat.com/



http://app.exiconglobal.com/



http://apis.io/

Open API Ecosystem


What’s Needed?


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)


http://developerexperience.org/

http://developer-support-handbook.appspot.com/





http://dx.jeremiahlee.com/

http://developer.mashery.com/developer_experience






https://www.youtube.com/watch?feature=player_embedded&v=zpaB4VggaoE

http://fr.slideshare.net/GoAtlassian/developerexperience-summit



Dedicated Portal


Documentation


Code Samples & SDK


Tools


Marketplace


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


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/


http://apihackday.com/

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

http://en.wikipedia.org/wiki/Social_networking

http://en.wikipedia.org/wiki/Postal_code

http://www.meetup.com/

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.


https://github.com/

http://geekli.st/

http://stackoverflow.com/

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.


Managing Your API



API Delivery


API Management Is Now Required!


Managing API


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


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.


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.


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".


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.


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/


http://www.strikeiron.com/about-the-ironcloud-platform/



http://webshell.io/

http://apigee.com/

https://chrome.google.com/webstore/detail/apigees-api-test-console/bkiaphiohlfaoajkffmacholmcnapkpe

http://www.mashery.com/

http://3scale.net/

http://apiphany.com/

http://apiary.io/

http://www.strikeiron.com/

http://cloudsecurity.intel.com/api-management



http://apispark.com/

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.





https://developers.helloreverb.com/swagger/

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.


http://www.stormpath.com/

http://pagerduty.com/

https://www.runscope.com/

https://www.runscope.com/


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


http://techcrunch.com/2013/12/02/man-machine-and-how-they-relate-to-apis/


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


http://techcrunch.com/2013/12/02/man-machine-and-how-they-relate-to-apis/


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.



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/


http://techcrunch.com/2013/11/27/firebase-adds-zapier-integration-pairing-real-time-infrastructure-with-the-ability-to-connect-multiple-apps/

http://www.wibidata.com/

http://apigee.com/docs/app_services

http://www.proxomo.com/

https://ifttt.com/login

http://www.kinvey.com/

http://www.emergentone.com/

http://apispark.com/

http://www.anypresence.com/

What About The Human API?



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.


Lucy McRae : Comment la technologie transforme-t-elle le corps humain ?

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.


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.


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/


http://humanapi.co/

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.


http://pandodaily.com/2013/01/01/the-human-battery-inventions-for-2013-and-beyond/

http://cleantechnica.com/2010/04/29/get-energy-from-your-shoe/

http://www.bbc.co.uk/news/science-environment-19470850

http://www.alternative-energy-news.info/human-power-is-the-future/

http://www.alternative-energy-news.info/human-power-is-the-future/

Best Practices and Lessons Learned



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


Five Keys To Great API


Dos & Don’ts Tips To Avoid Pitfalls

Dos

① API first, Mobile second, Web third

② Do your homework (Who, What, How)

③ Start “small” in terms of functionalities (you can always add but you can never remove)

④ Provide a compelling value proposition to drive adoption and grow your API ecosystem

⑤ Remain flexible to evolve with the needs of your user base

Don’ts

① API as a “side project”

② Neglect developers

③ Bad documentation (or inexistent)

④ Bad sample code/examples (or inexistent)

① No or unclear Terms & Conditions



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



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


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


Never Forget !!!


The great list of resources used to build this presentation


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)


http://www.3scale.net/

http://www.3scale.net/wp-content/uploads/2012/06/What-is-an-API-1.0.pdf

http://fr.slideshare.net/3scale/the-api-economy-api-provider-perspective-european-identity-summit-2012

http://fr.slideshare.net/3scale/apis-for-biz-dev-20-which-business-model-9672038

http://www.3scale.net/api-economy/ebooks/winning-in-the-api-economy/

http://fr.slideshare.net/3scale/how-apis-are-changing-software-development

http://fr.slideshare.net/3scale/the-api-and-appification-of-the-web

http://apievangelist.com/

http://apievangelist.com/2012/06/15/roundup-of-20-api-service-providers-in-2012/

http://blog.apievangelist.com/2011/02/28/if-you-build-it-they-will-come/


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)


http://apicommons.org/

http://kinlane.github.io/talks/apidays/bringing-api-design-out-of-the-shadows-and-into-the-commons/

http://fr.slideshare.net/3scale/towards-an-api-commons

https://apigee.com/about/

http://fr.slideshare.net/samramji







http://info.apigee.com/Portals/62317/docs/web api.pdf

http://www.fabernovel.com/

http://www.slideshare.net/faberNovel/6-reasons-why-apis-are-reshaping-your-business

http://fr.slideshare.net/faberNovel/why-shouldicareaboutap-is4


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)


http://www.layer7tech.com/

http://fr.slideshare.net/rnewton/api-business-roi

http://www.slideshare.net/rnewton/be-my-api

http://www.youtube.com/watch?v=xPn6VxuKOzM

http://www.programmableweb.com/

http://www.slideshare.net/jmusser/open-apis-whats-hot-whats-not-12506063

http://fr.slideshare.net/jmusser/j-musser-apibizmodels2013

http://fr.slideshare.net/jmusser/what-makes-a-great-open-api

http://www.youtube.com/watch?v=lFv5lH7nNX8

http://restlet.org/

http://fr.slideshare.net/restlet/20131202-ap-idays-paris

Twitter

http://www.twitter.com/welkaim

Travel 2.0

http://www.netvibes.com/travl20

Linkedin

http://fr.linkedin.com/in/williamelkaim

Blog

http://www.reimagine.fr/

Contact: [email protected]

112



http://www.netvibes.com/travl20





mailto:[email protected]


api part 2 - creating and managing your api

Technology