Developing Profitable APIs - John Fraser - Platform A

  • View
    2.059

  • Download
    2

Embed Size (px)

DESCRIPTION

 

Text of Developing Profitable APIs - John Fraser - Platform A

  • 1. John Fraser CTO, buy.at

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.

15. Design Considerations

  • Server-Side Design Pattern

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

17. Design Considerations

  • Client-Side Design Pattern

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 rdparty APIs.
    • Solution 2: JSON and Dynamic Scripting
      • Dynamically add a
      • Relies on the API using REST requests and JSON responses.
    • Solution 3: 3 rdParty 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 rdparty 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 retu