petr dvořák: mobilní webové služby pohledem iphone developera
DESCRIPTION
Jak nejlépe uchopit komunikaci mezi mobilním zařízením a síťovými službami, jak nastavit spolupráci, pokud server a klient vyvíjí různé, často vzdálené organizace, a proč vůbec psát webové služby, když máme mobilní internet...TRANSCRIPT
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