Changes between Version 2 and Version 3 of WifidogAPI

Show
Ignore:
Timestamp:
09/25/09 18:15:25 (10 years ago)
Author:
gbastien
Comment:

Added some thoughts on how the api would work

Legend:

Unmodified
Added
Removed
Modified
  • WifidogAPI

    v2 v3  
     1Created by Sylvain Carle, updated by Geneviève Bastien 
     2 
     3= Wifidog API = 
     4 
    15This page is used to define what data is exposed from the Auth Server thru and API for the purpose of using an independent CMS for the portal pages available to users. 
     6 
     7== What == 
    28 
    39* UserInfo 
     
    2834 
    2935 
     36== How ==  
    3037 
     38''This is open for discussion and are only thoughts by gbastien'' 
     39 
     40Following on some other discussions on the wiki ([wiki:doc/developer/WiFiDog_V2] and [wiki:doc/developer/WiFiDogProtocol_V2])  
     41 
     42The data should be requested and passed in standard ways, using a RESTful web service. 
     43 
     44The request would be a simple http GET with the query string containing all necessary information to return the data. 
     45 
     46Here are the possible parameters 
     47||'''Parameter''' ||'''Possible values'''||'''Description'''|| 
     48||action||get,list|| What kind of action is requested from the service || 
     49||object_class||user, node, network|| What kind of data is requested || 
     50||object_id|| || The object id of the object whose details are being requested|| 
     51||fields || ||The fields to return || 
     52||f (optional default:json)||json,xml|| The format of the response (only json would be implemented for now) || 
     53||v (optional default:1.0)||1.0|| The version of the web service protocol (to be forward compatible, just in case) || 
     54 
     55A typical request would look like this 
     56{{{ 
     57/ws/index.php?action=list&object_class=Node&&fields=name,connectedusers&f=json&v=1.0 
     58}}} 
     59 
     60The response would be in the form of a json string.  The advantages of json are discussed at other places on this wiki ().   The response would look something like this: 
     61{{{ 
     62{ 
     63    { 
     64        "name":"hotspot1name", 
     65        "connectedusers": 
     66         {  
     67             "user1":  
     68             { 
     69                 "name":"user1name" 
     70                 "url":"user1url" 
     71             } 
     72             "user2": 
     73             { 
     74                  "name":"user2name", 
     75                  "url":"user2url" 
     76             } 
     77         } 
     78    }, 
     79    { 
     80         "name":"network2name", 
     81         ... 
     82    } 
     83} 
     84}}} 
     85 
     86=== Some thoughts to keep in mind === 
     87 
     88While in the beginning, the purpose of this web service is to expose some data to CMS servers that will make use of it, we must keep in mind that we're opening another door on the auth server.  No data must pass through this door that wouldn't be publicly available anyway from the auth server. 
     89 
     90As for more sensitive data that would usually require a certain level of permission, since there would be no session with this web service, we'd need a scheme to pass authentication data to the request that cannot be overheard.  SSL would be necessary for that, as some personal authentication data like a password or hash would be passed along the way.