High level discussion about the best ways to use id.net APIs for hosts or SDKs. Written by EddieJ

1. id.net APIs for Hosts
HIGH LEVEL DISCUSSION ABOUT THE BEST WAYS TO USE ID.NET

2. Why use id.net?
o Prioritizing the users
o Economies of scale
o Layered feature sets
o Growing the audience

3. Topology
What it looks like to use id.net

4. Client Side Only

5. Server Side Only

6. Mixed client and server side

7. Client Side VS. Server Side
Client Server
Easy to implement Requires a server
Less secure More secure
Difficult to track Easier to monitor
Distributed Centralized
On demand Preloaded or fetched

8. Push Topology

9. Push VS. Pull
Push Pull
Difficult to implement Easier to implement
Server side Server or client side
Faster updates Slow updates with long polling
Less resource intensive* More resource intensive*

10. What is Available?
SDKs
oJavascript
oFlash (legacy)
Libraries
oOmniauth-idnet
oOauth2 Gem
oSimple-oauth2
oOauth-server-php
APIs
oThe Oauth2 API set
oSession API set (legacy)
oThe old push API
oThe new push API

11. Push API
Application setting page on id.net
Response format JSON
{
“data”: {},
“appid”: “123”,
“pid”: “432”,
“hash”: “sha256 sig”
}

12. Conclusion
o Using id.net can help a platform grow
o Understanding the topology of client, server, and mixed networks
o Client side and server side have many trade offs
o Exploring the current push APIs could add efficacies to a project
o There is still a strong use case for request/response pulling

13. What are your questions?
Ideas, comments, feedback