A quest for simplicity

A quest for simplicity in (AP)I history.
Talk given at API Days London 2015.

Transcript

1. Arnaud Lauret @apihandyman A quest for simplicity AXA Banque From depths of IS to heights of API
2. One does not simply start a quest without a goal The events depicted in this talk are fictitious. Any similarity to any information system living or dead is merely coincidental.
3. What is your quest?
5. What is your favorite word in API?
6. Application?
7. Programming?
8. Interface?
9. Interface!
10. The place at which independent and often unrelated systems meet and interact with each other
11. Photos of interface with my hands
13. What have they in common?
14. Us
15. People (Even APIs)
16. API = UI for people building programs
17. What’s happening behind an interface? The microwave oven parable
18. Abstraction A picture is worth a thousand words
20. What do we seek when using an interface (especially an API) ?
21. Simplicity
22. Easy to use
23. Easy to understand Error 1543 Missing email
24. Adapted to the targeted audience
25. So, what is our quest?
26. Simplify
27. Core Banking System A long time ago...
28. This is an interface
29. Access
30. IVR
31. Interactive Voice Response CBS Database CBS Non CBS Database IVR ZBAL0 ZBALV ZBALA ZBALY
32. FWW
33. Minitel CBS Database CBS Non CBS Database IVR MIN MQ Message: F1202167754151912540123777463779FRF0300020160917
34. Is interfacing with CBS simple? • Is it easy to use? • It it easy to understand? • Is the abstraction adapted to the audience?
35. So, it’s not simple
36. A few years laters... Web services
37. This is a dinosaur
38. At that time... CBS Database CBS Non CBS Database IVR MIN WEB
39. SOA(P)
40. SOA Principles • Service • Loose coupling • Reusability
41. SOAP Protocol • Use HTTP as a transport protocol • XML based • Input message contains the action to trigger and the data
42. Service or you’re ired!
43. SOA(P) CBS Database CBS Non CBS Database MIN IVR WEB SOAP services
44. Several years later
45. SOA(P) CBS Database CBS Non CBS Database IVR WEB JBOWS IVR WEB
46. Is interfacing with SOA simple? • Is it easy to use? • It it easy to understand? • Is the abstraction adapted to the audience?
47. Better but not awesome...
48. A few years ago ... APIs
50. Mobile
51. Middleware IVR WEB SOAP services MMW
52. ROAST
53. ROAST API recipe 1. Take a SOAP/XML web service name add a / before it 2. Choose randomly an HTTP method between GET, PUT, POST, PATCH or DELETE, put it before the / 3. Transform input/output data from XML to JSON 4. If the method is GET or DELETE, put all parameters in query variables 5. And be sure to always return HTTP status 200
54. The mobile team discovering GET /cancelTrfr?ztr1={id}
55. Several years later
56. Seriously
57. A REST API
58. Design First
59. Use resource instead of actions
60. A list of wire transfers /transfers
61. A wire transfers /transfers/{transferId}
62. Use relevant HTTP method
63. Create a transfer POST /transfers
64. Delete a pending wire transfer DELETE /transfers/{transferId}
65. Update a customer email PATCH /customers/me
66. Update a customer phone number PATCH /customers/me
67. Use relevant HTTP status
68. 403 Not enough money
69. 503 No transfer between 1 am and 2 am
70. Provide hypermedia controls
72. GET /accounts/C1 { “id”: “C1”, “balance”: <how much money I have>, “actions”: <hypermedia controls> [ { “name”: “transfer”, “method”: “POST”, “href”: “https://bank.com/transfers”} ] }
73. Different ways to fill the set of actions
74. #1 Takeshi’s Castle Knock Knock
75. 403 Forbidden { “code”: 1012, “message”: “Insufficient balance.” }
76. 503 Service unavailable { “code”: 1214, “message”: “No transfer between 1am and 2am.” }
77. #2 This is bowling. There are rules.
78. GET /accounts/C1 { “id”: “C1”, “balance”: -200, “actions”: [ ] }
79. GET /accounts/C1 { “id”: “C1”, “balance”: 20000, “actions”: [ ] }
80. #3 The Dude abides.
81. GET /accounts/C1 { “id”: “C1”, “balance”: -200, “actions”: [ { “name”: “transfer”, “status”: 403, “error”: { “code”: 1012, “message”: “Insufficient balance.”} } ] }
82. GET /accounts/C1 { “id”: “C1”, “balance”: 20000, “actions”: [ { “name”: “transfer”, “status”: 503, “error”: { “code”: 1214, “message”: “No transfer between 1am and 2am.”} } ] }
83. It it really so simple to design an API?
84. Is interfacing with a RESTful API simple? • Is it easy to use? • It it easy to understand? • Is the abstraction adapted to the audience?
85. Simple as a lego brick
86. To the heights of API and beyond... The end?