Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Developing Profitable APIs - John Fraser - Platform A

  • Login to see the comments

Developing Profitable APIs - John Fraser - Platform A

  1. 1. John Fraser CTO, buy.at
  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. asp.net, jQuery, Spry, script.aculo.us. </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?

×