RESTful frameworks for Android, iOS...?
My company is reworking its API and wants to make everything RIGHT for this time ;) Thats the setup...
- We are delivering data to clients over the internet.
- Clients are mobile handsets like iPhone, Androids, J2ME, Blackberry...
- The server is coded in Ruby on Rails
We want to achieve through a framework...
- Take use of ActiveResource on the clients.
- The framework should do the connection (REST), parsing and (dynamically) providing of models
- Licence must be open source.
- Authorization shall be included. We use OAuth and need to deliver the Access Token on any request. Maybe as parameter or in the HTTP-Header?
- HTTPS/SSL support
- Pagination and Relationships (with lazy loading) support would be great! Otherwize the framework must be able to be adjusted for these things.
We already have found following frameworks and kindly ask you guys to evaluate them. Maybe one of you used some of them or something different...
Android: RESTProvider from Novoda / Carl-Gustaf Harroch
- Providers offer an abstraction from data sources on Android and the RESTProvider Automatically parses RESTful API responses into a Provider. RESTProvider is an implementation of all commonly re-implemented functionality when dealing with web services in Android. Users can seamlessly interface with any Web Service API which provides JSON or XML as a response. To query a RESTProvider in an activity a user need only specify an endpoint and then query an APIs RESTful functions. RESTProvider also handles all HTTP querying & caching.
- Haven't found much documentation other than that
- Provides caching as well
- Release + Documentation is planned for early 2011
iOS: http://iphoneonrails.com/
- Lib for communication between iOS and Rails
- RESTful and "ActiveResource"-based
- includes XML/JSON Parser
- free licence
- pagination?, android?, lazy loading?
- Android: Hand made approach with the use of cursors backed by a SQLLite DB
- intended to be very performant and best practice of Android
- uses cursors
- Android: Spring Android Rest Template Module
- Spring's RestTemplate is a robust, popular Java-based REST client. The Spring Android Rest Template Module provides a version of RestTemplate that works in an Android environment.
- Android: You always should take a look at this video of Google IO 2010 when thinking serious about REST
- Android: Feed Framework
- com.google.android.feeds
- A collection of classes to help you build content providers. The framework is specially designed to help connect your application to Web APIs.
Answer
I am the author of the RESTProvider. Still very early stage so I would not recommend to use it in production. I have been using it on several projects which are in production but I adapted most the code to specific needs. I will try to get a public stable API by the end of the year.
In regards to reworking the API, I would suggest the following:
- Use GZip compression
- Use ETags for caching
- Use standards with no modification (I saw cases where the naming changed from oauth_token to my_token which makes most library useless without modification) - OAuth/REST
- Use creation/modified timestamp and remote ids for all objects in order to enable caching client side (SQLite conflict clauses): {"myobject": {"createdAt": xxxx, "rid": "hashvalue"}} 4a. Use a good way to identify the object returned for user/activity/application: opensocial uses "application id" + "user id" + "activity id"
- Prefer JSON over XML
- Prefer simplicity (lowest depth possible)
- Return the full object with the one to many relationship within that object: {"parent":.... "has": {"full object not just the ID"} }
- Don't return IDs only ( "category": [ 2,3,4] should be "category": [{"name": "testing", "id": 2},{"name": "production", "id": 3 }} )
- Consider each call to be independent of each other (i.e. I should have enough information for call http://test.com/object.json to populate my views)
For documentation: 1. provide test servers 2. provide cUrl for testing 3. provide sample scripts in java/php/ruby etc...
That s all I can think for now. I might add ontop of this as I come with more suggestion.