Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Developing Profitable APIs - John Fraser - Platform A

•Download as PPT, PDF•
•
auexpo Conference
auexpo Conference

The document discusses several challenges and considerations for networks and affiliates in designing and implementing APIs and mashups. It addresses questions around API architecture design, defining standard data formats, scalability, read/write functionality, and support for affiliates. It also covers common challenges like complex programming, browser compatibility, and maintenance, and potential solutions. While mashups require more development and maintenance costs, they also provide opportunities to attract users through new interactive features and access new markets.

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

More Related Content

Developing Profitable APIs - John Fraser - Platform A

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