John FraserCTO, 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 ProvisionRead/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

Client

3rd Party API ServerApplication Server

1. R

eque

st

4. R

espo

nse

3. API Response

2. API Request

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

Client

3rd Party API ServerApplication Server1.

Req

uest

2. R

espo

nse

4. API R

esponse3. A

PI Request

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 patternsThe 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 + SolutionsSame 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 3rd 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: 3rd Party components• Some plug-ins allow XMLHTTPRequest like functionality.• May be broken with later security updates.

Challenges + Solutions

Browser CompatibilityThe 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 HandlingYou can never rely on 3rd 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

MaintenanceThe 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?