1.
iPhone developer's view at the
mobile web-services
Petr Dvořák
iPhone Developer
Prague, 24th September 2010

2.
The key message
Well, iPhone might not last forever.
Web-services written for it will.

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

4.
Motivation

5.
Renaissance of the web-services
 Back in 2005, WAP
was pretty cool
 Web-services are for
corporations and
bussiness applications

6.
Renaissance of the web-services
 Today, the web-services
are „custommer goods“

7.
Trends today
 Social apps are on the roll...

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

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

10.
Two points to remember for now...
 Importance of the web-services rapidly grows
 If you didn't start yesterday, it might be too late

11.
Technical matters

12.
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

13.
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

14.
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>

15.
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

16.
Which API format to choose?

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

18.
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

19.
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”/>

20.
Plists
 You can use plists as a base format for API

21.
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

22.
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>

23.
Optimal granularity?

24.
What is granularity?
„The way you split the complete model stored
on the server into individual resources“

25.
What is granularity?
 Extreme: One huge XML file with all information
vs. Many small files
 Which direction should you choose?

26.
Choose the right one, dummies! :-)

27.
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

28.
Authentication on iPhone

29.
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?

30.
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];
}

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

32.
Form-based authentication
NSURL *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];

33.
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...

34.
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

35.
Step 1: Request token
Asks a request token
Consumer Provider
Grants request token

36.
Step 2: Direct user to provider
Points user to providers login page
Consumer
User re-writes PIN (verifier) in the app

37.
Step 3: Access token
Asks an access token (uses PIN)
Consumer Provider
Grants access token

38.
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

39.
OAuth in an actuall app

40.
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

41.
XAuth
 XAuth is still OAuth
 Credentials processed on client during the dance
 Username and password are exchanged for the access
tokens

42.
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!

43.
Caching

44.
Caching
 Better feel for user
 Less data transferred
 Technologies
 PLists
 SQLite database + nice wrappers (fmdb, TouchSQL, ...)

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

46.
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

47.
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

48.
HTTP Responses

49.
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

50.
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;
}
}

51.
Little appeal

52.
Little appeal
Machines are people too...

53.
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

54.
Real-world „web-services“
 vs. YAML API after registration
 10 API queries per 1 ad query
 Enforcable
 app does not follow rule → BAN

55.
Romanian hydrometeorological
institute
 vs. Paid XML/CSV
exports
 Rational pricing
 Now: ~ 10k EUR/year

56.
The key message
Well, iPhone might not last forever.
Web-services written for it will.

57.
Q&A
http://twitter.com/inmite