• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why apis

Why apis



Introduction to API development, the advantages and the challenges of this model. Delivered as a part of the ASPgems' innovation upgrade talks at Sanitas

Introduction to API development, the advantages and the challenges of this model. Delivered as a part of the ASPgems' innovation upgrade talks at Sanitas



Total Views
Views on SlideShare
Embed Views



5 Embeds 14

http://planeta.aspgems.com 10
https://twitter.com 1
https://si0.twimg.com 1
https://www.linkedin.com 1
http://www.linkedin.com 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

    Why apis Why apis Presentation Transcript

    • ¿Por qué APIs?http://delicious.com/supercoco9/aspgems_sanitas_apis javier ramirez @supercoco9 @ASPgems
    • Corporate systems: DCOM, RPC, SOAP, MQs Web: Syndication, widgets, brokers
    • APP Economy App AppPeople App Store Developer
    • APP Economy App App IT InternalPeople App Store Developer Team Systems
    • APP Economy App App World of API InternalPeople App API Store Developer APIs Team Systems
    • ServiceOrientedArchitecture
    • THE SOA MANIFESTOService orientation is a paradigm that frames whatyou do.Service-oriented architecture (SOA) is a type ofarchitecture that results from applying serviceorientation.
    • Business value over technical strategyStrategic goals over project-specific benefitsIntrinsic interoperability over custom integrationShared services over specific-purposeimplementationsFlexibility over optimizationEvolutionary refinement over pursuit of initialperfection
    • 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 buildthings — 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 bedoing.Build digital services, not websitesOur service doesn’t begin and end at our website. It might start with a search engineand end at the post office. We need to design for that, even if we can’t control it. Andwe need to recognise that some day, before we know it, it’ll be about different digitalservices 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 shouldmake sure our underlying approach is consistent. So our users will have a reasonablechance 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, withthe world. Share code, share designs, share ideas, share intentions, share failures. Themore eyes there are on a service the better it gets — howlers get spotted, betteralternatives get pointed out, the bar gets raised.
    • Amazon st1 class API
    • Amazon Home Page~ 150 API callsLatencyAsynchronous architectures
    • ScalabilityAutonomyAsynchronyControlled concurrency and parallelismDecentralizeDecompose into small blocksFailure tolerantLocal responsibilityRecovery built-inSimplicitySymmetry
    • Better projectmanagementBetter software qualityFaster development
    • CAP theoremConsistencyAvailabilityPartitioning
    • ACID :(AtomicConsistentIsolatedDurableBASE :)Basically AvailableSoft stateEventually consistent
    • RESTREpresentationalStateTransfer
    • REST architectureclient-serverstatelesslayeredcacheable
    • REST elements (i)Resources Resource Identifiers Resource metadata
    • REST elements (ii)Uniform interface operations Representations Representation 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 deerrores, Analítica, Monetización,Documentación, First class APIAPI UsabilityReal time APIs
    • Systems development has changed. Now go outthere and start building interoperating services.