¿Por qué APIs?http://delicious.com/ supercoco9 /aspgems_sanitas_apis

javier ramirez@supercoco9

@ASPgems

Corporate systems: DCOM, RPC, SOAP, MQsWeb: Syndication, widgets, brokers

APP Economy

People AppApp

StoreApp

Developer

APP Economy

People ITTeam

AppApp

StoreInternalSystems

AppDeveloper

APP Economy

People APITeam

APIAppWorld of

APIsApp

StoreInternalSystems

AppDeveloper

Service OrientedArchitecture

THE SOA MANIFESTOService orientation is a paradigm that frames what you do.

Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.

Business value over technical strategy

Strategic goals over project-specific benefits

Intrinsic interoperability over custom integration

Shared services over specific-purpose implementations

Flexibility over optimization

Evolutionary refinement over pursuit of initial perfection

UK governmenthttps://www.gov.uk/designprinciples

Do lessGovernment should only do what only government can do. If someone else is doing it — link to it. If we can provide resources (likeAPIs) that will help other people build things — do that. We should concentrate on the irreducible core.

Do the hard work to make it simpleMaking something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.

Build digital services, not websitesOur service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.

Be consistent, not uniformWherever possible we should use the same language and the same design patterns — this helps people get familiar with our services. But, when this isn’t possible, we should make sure our underlying approach is consistent. So our users will have a reasonable chance of guessing what they’re supposed to do.

Make things open: it makes things betterWe should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers get spotted, better alternatives get pointed out, the bar gets raised.

Amazon

1st class API

Amazon Home Page~ 150 API calls

LatencyAsynchronous architectures

Scalability AutonomyAsynchronyControlled concurrency and parallelismDecentralizeDecompose into small blocksFailure tolerantLocal responsibilityRecovery built-inSimplicitySymmetry

Better project management

Better software quality

Faster development

CAP theoremConsistencyAvailabilityPartitioning

ACID :(AtomicConsistentIsolatedDurable

BASE :)Basically AvailableSoft stateEventually consistent

RESTREpresentationalStateTransfer

REST architecture

client-serverstatelesslayeredcacheable

REST elements (i)

ResourcesResource IdentifiersResource metadata

REST elements (ii)

Uniform interfaceoperationsRepresentationsRepresentation metadata

REST elements (iii)

HATEOAS**Hypermedia as the engine of application state

REST elements (iv)

Optionally: code on demand

REST API aspectsModelo de recursos, Seguridad, Autenticación, Estado, Formatos, Versionado, Múltiples consumidores, Paginación, Escalabilidad, Cuotas, Metadatos, Cachés, Estados, Gestión de errores, Analítica, Monetización, Documentación, First class API

API UsabilityReal time APIs

Systems developmenthas changed.

Now go out there and start

building interoperating

services.