Developing Profitable APIs - John Fraser - Platform A


Published on

Published in: Technology
  • Be the first to comment

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

No notes for slide

Developing Profitable APIs - John Fraser - Platform A

  1. 1. John Fraser CTO,
  2. 2. Service Provision <ul><li>“ What challenges do Networks face when acting as a service provider?” </li></ul>
  3. 3. Service Provision <ul><li>API Architecture </li></ul><ul><ul><li>“ How should an API be designed?” </li></ul></ul><ul><ul><li>Service Orientated vs. Resource Orientated. </li></ul></ul><ul><ul><li>Resource Orientated </li></ul></ul><ul><ul><ul><li>Usually based around REST protocols. </li></ul></ul></ul><ul><ul><ul><li>Simpler to integrate, but less flexible. </li></ul></ul></ul><ul><ul><li>Service Orientated </li></ul></ul><ul><ul><ul><li>Could use protocols such as SOAP / XML-RPC. </li></ul></ul></ul><ul><ul><ul><li>More complex. </li></ul></ul></ul>
  4. 4. Service Provision <ul><li>Defining standard datasets </li></ul><ul><ul><li>“ How do we decide what data an API returns?” </li></ul></ul><ul><ul><li>Dimensionality </li></ul></ul><ul><ul><ul><li>Consider multiple degrees of freedom in a data request. </li></ul></ul></ul><ul><ul><ul><li>e.g. Holidays vary in location, duration, date, etc. </li></ul></ul></ul><ul><ul><li>Category mapping </li></ul></ul><ul><ul><ul><li>Ensure that categories are consistent across brands. </li></ul></ul></ul><ul><ul><ul><li>e.g. Mobile phone features. </li></ul></ul></ul>
  5. 5. Service Provision <ul><li>Scalability </li></ul><ul><ul><li>“ How do we avoid the Slashdot effect?” </li></ul></ul><ul><ul><li>Client Isolation </li></ul></ul><ul><ul><ul><li>Preventing one client from monopolising resources. </li></ul></ul></ul><ul><ul><li>Request Quotas </li></ul></ul><ul><ul><ul><li>Another method for isolating clients. </li></ul></ul></ul><ul><ul><li>Latency </li></ul></ul><ul><ul><ul><li>Need to ensure that latency scales well with load. </li></ul></ul></ul>
  6. 6. Service Provision <ul><li>Read/Write Functionality </li></ul><ul><ul><li>“ Why do networks often only offer read functionality?” </li></ul></ul><ul><ul><li>Read only </li></ul></ul><ul><ul><ul><li>Simpler, more secure. </li></ul></ul></ul><ul><ul><ul><li>Very commonly offered. </li></ul></ul></ul><ul><ul><li>Read / Write </li></ul></ul><ul><ul><ul><li>Needs an authentication method. </li></ul></ul></ul><ul><ul><ul><li>Uncommon to see in a client side mashup. </li></ul></ul></ul>
  7. 7. Network Support <ul><li>“ What support can Networks give to help affiliates integrate with an API?” </li></ul>
  8. 8. Network Support <ul><li>Documentation </li></ul><ul><ul><li>Needs to be accessible to independent developers. </li></ul></ul><ul><ul><li>Needs to make no assumptions about prior knowledge. </li></ul></ul><ul><ul><li>Separation of protocol from transport can be useful. </li></ul></ul>
  9. 9. Network Support <ul><li>SDK / Tools </li></ul><ul><ul><li>Should be platform neutral if possible. </li></ul></ul><ul><ul><li>Should match existing technologies that clients use. </li></ul></ul>
  10. 10. Network Support <ul><li>Interoperability </li></ul><ul><ul><li>Reuse of industry standards should be encouraged. </li></ul></ul><ul><ul><ul><li>e.g. SOAP, JSON </li></ul></ul></ul><ul><ul><li>Should never force clients to make compromises. </li></ul></ul>
  11. 11. Network Support <ul><li>Backwards Compatibility </li></ul><ul><ul><li>Ensure legacy features are retained with new product releases. </li></ul></ul><ul><ul><li>Provide clear migration paths and timelines when features are deprecated. </li></ul></ul>
  12. 12. Network Support <ul><li>Access to Support </li></ul><ul><ul><li>Dedicated technical support. </li></ul></ul><ul><ul><li>Sponsorship of community efforts. </li></ul></ul><ul><ul><li>Availability of training. </li></ul></ul>
  13. 13. Design Considerations <ul><li>“ What should affiliates be considering when implementing a Mashup?” </li></ul>
  14. 14. Design Considerations <ul><li>Client-Side versus Server-Side integrations </li></ul><ul><ul><li>Server-Side </li></ul></ul><ul><ul><ul><li>a.k.a. “Traditional Web App”. </li></ul></ul></ul><ul><ul><ul><li>Uses technologies such as PHP, ASP and JSP. </li></ul></ul></ul><ul><ul><li>Client-Side </li></ul></ul><ul><ul><ul><li>a.k.a. “Mashup” </li></ul></ul></ul><ul><ul><ul><li>Uses technologies such as AJAX and XMLHTTPRequest. </li></ul></ul></ul>
  15. 15. Design Considerations <ul><li>Server-Side Design Pattern </li></ul>
  16. 16. Design Considerations <ul><li>Server-Side Strengths </li></ul><ul><ul><li>Good compatibility, easy to test. </li></ul></ul><ul><ul><li>Uses simple programming patterns. </li></ul></ul><ul><li>Server-Side Weaknesses </li></ul><ul><ul><li>Can be slow to respond. </li></ul></ul><ul><ul><li>Not as flexible. </li></ul></ul><ul><ul><li>“Feels like a web page” </li></ul></ul>
  17. 17. Design Considerations <ul><li>Client-Side Design Pattern </li></ul>
  18. 18. Design Considerations <ul><li>Client-Side Strengths </li></ul><ul><ul><li>Greater feature set available. </li></ul></ul><ul><ul><li>“ Feels like an interactive application” </li></ul></ul><ul><li>Client-Side Weaknesses </li></ul><ul><ul><li>More complicated programming or tools required. </li></ul></ul><ul><ul><li>Issues with browser compatibility. </li></ul></ul><ul><ul><li>Easier to reverse engineer. </li></ul></ul>
  19. 19. Challenges + Solutions <ul><li>“ What are the common challenges you will face creating a mashup?” </li></ul><ul><li>“ What solutions are available to address these?” </li></ul>
  20. 20. Challenges + Solutions <ul><li>Complex programming patterns </li></ul><ul><ul><li>The introduction of AJAX programming introduces complexities. These include race conditions, threading issues, exception handling, etc. </li></ul></ul><ul><ul><li>Solutions: </li></ul></ul><ul><ul><ul><li>Use a standard library to hide the complexity. e.g., jQuery, Spry, </li></ul></ul></ul><ul><ul><ul><li>Pay someone else to develop it. </li></ul></ul></ul>
  21. 21. Challenges + Solutions <ul><li>Same Origin Policy </li></ul><ul><ul><li>Browsers will only allow an XMLHTTPRequest to the domain of the container page. </li></ul></ul><ul><ul><li>Solution 1: AJAX Proxy </li></ul></ul><ul><ul><ul><li>Make all requests to your own domain, and implement a server-side bridge to 3 rd party APIs. </li></ul></ul></ul><ul><ul><li>Solution 2: JSON and Dynamic Scripting </li></ul></ul><ul><ul><ul><li>Dynamically add a <script> tag referencing a REST API source. </li></ul></ul></ul><ul><ul><ul><li>Relies on the API using REST requests and JSON responses. </li></ul></ul></ul><ul><ul><li>Solution 3: 3 rd Party components </li></ul></ul><ul><ul><ul><li>Some plug-ins allow XMLHTTPRequest like functionality. </li></ul></ul></ul><ul><ul><ul><li>May be broken with later security updates. </li></ul></ul></ul>
  22. 22. Challenges + Solutions <ul><li>Browser Compatibility </li></ul><ul><ul><li>The growth in the number of browsers, plus increased feature development, makes the intended audience a moving target. </li></ul></ul><ul><ul><li>Solutions: </li></ul></ul><ul><ul><ul><li>Stick to supported standards. </li></ul></ul></ul><ul><ul><ul><li>Use standard libraries if possible. </li></ul></ul></ul><ul><ul><ul><li>Test as many browsers as possible. </li></ul></ul></ul>
  23. 23. Challenges + Solutions <ul><li>Exception Handling </li></ul><ul><ul><li>You can never rely on 3 rd party APIs to return a response. </li></ul></ul><ul><ul><li>Solutions: </li></ul></ul><ul><ul><ul><li>Ensure your application is robust to API failures. </li></ul></ul></ul><ul><ul><ul><li>Avoid solutions that are latency sensitive. </li></ul></ul></ul><ul><ul><ul><li>When testing, use proxies to simulate failures. </li></ul></ul></ul>
  24. 24. Challenges + Solutions <ul><li>Maintenance </li></ul><ul><ul><li>The added complexity of client-side apps, plus the changing browser landscape, means that applications need to be maintained. </li></ul></ul><ul><ul><li>Developers charge by the hour… </li></ul></ul><ul><ul><li>Solutions: </li></ul></ul><ul><ul><ul><li>Insist standards are followed. </li></ul></ul></ul><ul><ul><ul><li>Develop it yourself. </li></ul></ul></ul><ul><ul><ul><li>Make sure the work is justified by the ROI. </li></ul></ul></ul>
  25. 25. Making Websites Profitable <ul><li>Negative factors affecting profitability </li></ul><ul><ul><li>The costs of developing and maintaining a mashup are higher than a traditional site. </li></ul></ul><ul><ul><li>It is more difficult to search optimise the content of an interactive site. </li></ul></ul>
  26. 26. Making Websites Profitable <ul><li>Positive factors affecting profitability </li></ul><ul><ul><li>Interactive functionality can attract return visits. </li></ul></ul><ul><ul><li>Increased PR value. </li></ul></ul><ul><ul><li>Opportunity to hit new markets. e.g. iPhone. </li></ul></ul><ul><ul><li>USP / differentiator for sites. </li></ul></ul>
  27. 27. Conclusions <ul><li>APIs are about removing the dependency on the Network / Merchant for interactive functionality. </li></ul><ul><li>They require a higher initial investment, but are a huge opportunity for affiliates to differentiate sites and attract and retain users. </li></ul>
  28. 28. Questions?