- webexpo 2010

iPhone developer's view at the mobile web-services

Prague, 24th September 2010

Petr DvořákiPhone Developer

Well, iPhone might not last forever. Web-services written for it will.

The key message

What we will cover ... Motivation Technical matters Small appeal Q&A

Motivation

Renaissance of the web-services Back in 2005, WAP

was pretty cool Web-services are for

corporations and bussiness applications

Renaissance of the web-services Today, the web-services

are „custommer goods“

Trends today Social apps are on the roll...

Trends today Modern media changes – news are everywhere...

Trends today iPhone is the business phone (sorry...)

Two points to remember for now...

Importance of the web-services rapidly grows

If you didn't start yesterday, it might be too late

Technical matters

XML-RPC/SOAP? Why not... Procedural approach to webservices Libraries already exist

„Cocoa XML-RPC Framework“ used in WordPress Any C/C++ library will work

And the winner is ... RESTful + XML / JSON (YAML , PList …)

REST principles implemented above HTTP protocol HTTP POST, GET, PUT, DELETE

Data oriented – the main unit is resource vs. procedural approach

Popularity originates in comprehensibility

Example of a REST API - Corkbin<nearest lat="50.104571" lon="14.496027" max="2">

<wine hash="w722833d" id="1284919812900_475001_4" recommended="false"

timestamp="1284919812900" userId="475001">

<comment>Pink wine :)</comment>

<img>wineImage/p1284919812900_475001_4</img>

<gps lat="50.129139" lon="14.471089"/>

</wine>

<wine hash="w14a6cb4" id="1284902438029_125008_8" recommended="true"

timestamp="1284902438029" userId="125008">

<comment>Nice wine from France</comment>

<img>wineImage/p1284902438029_125008_8</img>

<gps lat="45.192108" lon="9.208828"/>

</wine>

</nearest>

Little issue to keep in mind ... Not all servers support all HTTP methods, when

you need them „Pure RESTful“ needs all HTTP methods to work

Fix your servers and frameworks

Which API format to choose?

XML vs. JSON – and the winner is ...

XML vs. JSON Choose what fits you best (or just start a flame...) XML

Older, more robust, chatty format with more adult tools TouchXML, KissXML, NSXMLParser, ...

JSON Better suits object serialization abstraction, compact TouchJSON, JSON Framework

Little remark on XML being chatty …

<!-- 76 chars //-->

<person>

<name>Petr</name>

<surname>Dvorak</surname>

<born>1985</born>

</person>

<!-- 50 chars //-->

<person name=”Petr” surname=”Dvorak” born=”1985”/>

Plists You can use plists as a base format for API

Plists (Property List) You can use plists as a base format for API

What the heck is plist? Apple's XML based format with a binary variant

Binary variant is default, and very space efficient Used for object serialization and app properties

Plist - Example<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"

"http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>Year Of Birth</key>

<integer>1965</integer>

<key>Kids Names</key>

<array>

<string>John</string>

<string>Kyra</string>

</array>

</dict>

</plist>

Optimal granularity?

What is granularity?

„The way you split the complete model stored on the server into individual resources“

What is granularity? Extreme: One huge XML file with all information

vs. Many small files Which direction should you choose?

Choose the right one, dummies! :-)

Practical testing One resource should have no more than 80kB

GPRS: ~20-30 seconds to download (users don't die waiting)

3G: ~6-8 seconds (users don't get bored) Latency is still an issue – try to keep resources as

big as possible

Authentication on iPhone

Basic HTTP authentication Client-side method Almost for free on iPhone

Implement authentication challenge callback … or just add credentials in the URL

Do you really want to consider this method?

Basic HTTP authentication-(void)connection:(NSURLConnection *)connection

didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge {

// you can use [challenge previousFailureCount] here

NSURLCredential *newCredential = [NSURLCredential

credentialWithUser:USERNAME

password:PASSWORD

persistence:NSURLCredentialPersistenceForSession];

[[challenge sender] useCredential:newCredential

forAuthenticationChallenge:challenge];

}

Form-based authentication Long story short: You get it for free...

Form-based authenticationNSURL *url = [NSURL URLWithString:@”https://localhost/login.php”];

NSMutableURLrequest = [NSMutableURLRequest requestWithURL:url];

[request setHTTPMethod:@"POST"];

[request setValue:@"application/x-www-form-urlencoded"

forHTTPHeaderField:@"Content-Type"];

NSData *postData = [@”login=joshis&password=********”

dataUsingEncoding:NSUTF8StringEncoding];

[request setHTTPBody:postData];

[request setValue:[NSString stringWithFormat:@"%d", [postData length]]

forHTTPHeaderField:@"Content-Length"];

self.connection = [NSURLConnection connectionWithRequest:request

delegate:some_delegate];

[self.connection start];

Apparent problem ... Credentials are stored on device

For the purpose of auto-login Does not have to be an issue

Mobile device: Usually, it is... If not on HTTPS, content can be forged Any solution? Yes – let's dance...

OAuth Authentication protocol 3 subjects – user, consumer, provider

Consumer ~ Application at provider 3 stages – request, authorize, access On mobile device: OOB (out-of-brand) version

Step 1: Request token

Consumer Provider

Asks a request token

Grants request token

Step 2: Direct user to provider

Consumer

Points user to providers login page

User re-writes PIN (verifier) in the app

Step 3: Access token

Consumer Provider

Asks an access token (uses PIN)

Grants access token

OAuth – the good thing Access tokens are stored on the device, then used

in OAuth header (HTTP) These are not the username and password

And that's what we wanted Signature prevents content forgery

OAuth in an actuall app

OAuth – the bad thing You display a web page for authentication for your

app Either in app – user writes in untrusted context Or in Safari – workflow is horrible

The best security is achieved only in trusted browser

XAuth XAuth is still OAuth Credentials processed on client during the dance

Username and password are exchanged for the access tokens

OAuth/XAuth – implementation It is a heck of a lot of work to implement

OAuth/XAuth on the iPhone for the first time If you don't/can't use libraries

It is definitely worth it, if you have the patience Users' passwords and communication are safe

Web-service implementors: Do OAuth/XAuth!

Caching

Caching Better feel for user Less data transferred Technologies

PLists SQLite database + nice wrappers (fmdb, TouchSQL, ...)

Cache validation

Asking the server if the resource you have is up to date.

ETag Every resource has a “tag” associated with it on

“CREATE” operation on server (HTTP POST) Tag is updated on “UPDATE” operation on server

(HTTP PUT) ETag is sent in HTTP header with resource

ETag Client caches the ETag with the resource Client sends a “If-none-match” header with eTag

when asking for a resource If the resource is not modified, client receives a

response “304 – Not Modified” from server and cancels the connection

HTTP Responses

Error handling HTTP responses often ignored on the server side

Always returns 200 + XML with <error> elements … Wrong for a mobile clients

Download just to find out error occurred

Error handling- (void) connection:(NSURLConnection *)connection

didReceiveResponse:(NSURLResponse *)response {

int code = [((NSHTTPURLResponse*)response) statusCode];

if (code == 200) { // OK, alt. (code / 100 != 2)

} else if (code == 418) { // I'm a teapot

[self iMaTeaPot];

} else { // assume error here, switch depending on the response code

[self handleError:code];

[connection cancel];

self.connection = nil;

}

}

Little appeal

Little appeal

Machines are people too...

Little appeal Making public data hard to process by machines

does not help anyone And it does not stop anyone

Registration at least enforces some policy

Real-world „web-services“ vs. YAML API after registration

10 API queries per 1 ad query Enforcable

app does not follow rule → BAN

Romanian hydrometeorological institute

vs. Paid XML/CSV exports

Rational pricing Now: ~ 10k EUR/year

Well, iPhone might not last forever. Web-services written for it will.

The key message

Q&A

http://twitter.com/inmite