7. Behold, a versioned API
So, /api/users/ will default to version 1 of our API.
Is this a good idea? There’s a LOT of discussion about versioning APIs...
http://apiux.com/2013/05/14/api-versioning/
https://mathieu.fenniak.net/aint-nobody-got-time-for-that-api-versioning/
http://railscasts.com/episodes/350-rest-api-versioning
Do what feels comfortable / correct. I’m not too keen on having a default API route which may change behind-the-scenes, and
inadvertently break applications that use the API.
Monday, January 13, 14
12. Cool, we have a Users Resource which is accessible via the
routes we’ve created on /api/users... what does that have to
do with sending push-notifications to phones?
Monday, January 13, 14
13. How do Push Notifications work? (iOS)
Phase 1
Good documentation of the process can be found on Adobe’s site for Adobe AIR (seriously)
http://www.adobe.com/devnet/air/articles/ios-push-notifications.html
Monday, January 13, 14
Phase 2
14. Next, install a background processing
system of your choice
https://www.ruby-toolbox.com/categories/Background_Jobs
Monday, January 13, 14
17. Final example
•
•
A final example with some additional features is available [1]
•
Primary Gems used:
Much credit is due to Ryan Bates for the API skeleton [2] and authentication
implementation [3], and wellwithme.com for their original Android/iOS push
notifications tutorial. [4]
•
•
•
•
•
Sidekiq
Sidetiq
Grocer
•
Friendly ID
GCM
Active Model Serializers
[1] https://bitbucket.org/momer/example-mobile-pns/src
[2] http://railscasts.com/episodes/350-rest-api-versioning
[3] http://railscasts.com/episodes/352-securing-an-api
[4] http://blog.wellwith.me/how-to-send-ios-and-android-notifications-from-your-rails-backend
Monday, January 13, 14