Why apis


Published on

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

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Why apis

  1. 1. ¿Por qué APIs?http://delicious.com/supercoco9/aspgems_sanitas_apis javier ramirez @supercoco9 @ASPgems
  2. 2. Corporate systems: DCOM, RPC, SOAP, MQs Web: Syndication, widgets, brokers
  3. 3. APP Economy App AppPeople App Store Developer
  4. 4. APP Economy App App IT InternalPeople App Store Developer Team Systems
  5. 5. APP Economy App App World of API InternalPeople App API Store Developer APIs Team Systems
  6. 6. ServiceOrientedArchitecture
  7. 7. THE SOA MANIFESTOService orientation is a paradigm that frames whatyou do.Service-oriented architecture (SOA) is a type ofarchitecture that results from applying serviceorientation.
  8. 8. 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
  9. 9. UK governmenthttps://www.gov.uk/designprinciples
  10. 10. 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.
  11. 11. 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.
  12. 12. Amazon st1 class API
  13. 13. Amazon Home Page~ 150 API callsLatencyAsynchronous architectures
  14. 14. ScalabilityAutonomyAsynchronyControlled concurrency and parallelismDecentralizeDecompose into small blocksFailure tolerantLocal responsibilityRecovery built-inSimplicitySymmetry
  15. 15. Better projectmanagementBetter software qualityFaster development
  16. 16. CAP theoremConsistencyAvailabilityPartitioning
  17. 17. ACID :(AtomicConsistentIsolatedDurableBASE :)Basically AvailableSoft stateEventually consistent
  18. 18. RESTREpresentationalStateTransfer
  19. 19. REST architectureclient-serverstatelesslayeredcacheable
  20. 20. REST elements (i)Resources Resource Identifiers Resource metadata
  21. 21. REST elements (ii)Uniform interface operations Representations Representation metadata
  22. 22. REST elements (iii) HATEOAS**Hypermedia as the engine of application state
  23. 23. REST elements (iv)Optionally: code on demand
  24. 24. 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
  25. 25. Systems development has changed. Now go outthere and start building interoperating services.