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
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>
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
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];
}
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
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
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!
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
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
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
