Why apis
0 likes382 views
The document discusses the importance of APIs and service-oriented architecture (SOA) in modern digital services, emphasizing the need for intrinsic interoperability and shared services over custom solutions. It outlines principles for government digital services, such as simplicity, consistency, and openness, advocating for an approach that prioritizes user experience while managing complex underlying systems. Additionally, it touches on REST API elements and modern development practices to enhance project management and software quality.
Why apis
- 1. ¿Por qué APIs? http://delicious.com/supercoco9/aspgems_sanitas_apis javier ramirez @supercoco9 @ASPgems
- 2. Corporate systems: DCOM, RPC, SOAP, MQs Web: Syndication, widgets, brokers
- 3. APP Economy App App People App Store Developer
- 4. APP Economy App App IT Internal People App Store Developer Team Systems
- 5. APP Economy App App World of API Internal People App API Store Developer APIs Team Systems
- 7. THE SOA MANIFESTO Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
- 8. 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
- 10. Do less Government 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 simple Making 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 websites Our 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.
- 11. Be consistent, not uniform Wherever 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 better We 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.
- 12. Amazon st 1 class API
- 13. Amazon Home Page ~ 150 API calls Latency Asynchronous architectures
- 14. Scalability Autonomy Asynchrony Controlled concurrency and parallelism Decentralize Decompose into small blocks Failure tolerant Local responsibility Recovery built-in Simplicity Symmetry
- 15. Better project management Better software quality Faster development
- 17. ACID :( Atomic Consistent Isolated Durable BASE :) Basically Available Soft state Eventually consistent
- 20. REST elements (i) Resources Resource Identifiers Resource metadata
- 21. REST elements (ii) Uniform interface operations Representations Representation metadata
- 22. REST elements (iii) HATEOAS* *Hypermedia as the engine of application state
- 23. REST elements (iv) Optionally: code on demand
- 24. REST API aspects Modelo 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 Usability Real time APIs
- 25. Systems development has changed. Now go out there and start building interoperating services.