CUM API: Skillnad mellan sidversioner

Från Slackopedia
+rubriker
tempsparar
Rad 5: Rad 5:
*UTF-8-kodning
*UTF-8-kodning
* ...
* ...
== Grundstruktur ==
=== Klient ===
Ett ''call'' till CUM's API ser ut såhär:
<cum>
  <apiKey>%apiKey%</apiKey>
  <command>%kommando%</command>
  <params>
    ...
  </params>
</cum>
Om man t.ex. vill kontrollera en användares användarnamn och lösenord mot API:et kan ett riktigt ''call'' se ut:
<cum>
  <apiKey>a3b4b2F2C2hg3ifs7</apiKey>
  <command>auth</command>
  <params>
    <username>användarnamn</username>
    <password>md5-summa-av-lösenord</password>
  </params>
</cum>
=== Server ===
Serversidans XML-svar är snarlikt, och är på formen:
<cum>
  <responseCode>%responseCode%</responseCode>
 
  [<result>
    ...
  </result>]
</cum>
Som svar på ovanstående klientsnutt skulle man t.ex. kunna få som svar:
<cum>
  <responseCode>102</responseCode>
</cum>
som talar om att lösenordet är felaktigt.


== Kommandon ==
== Kommandon ==


=== auth ===
'''%apiKey%''' är rakt igenom din API-nyckel.
...
 
<h3 style="color: #c00;">auth</h3>
 
Skickar en begäran om autentisering av en användare.
 
====Struktur====
 
<cum>
  <apiKey>%apiKey%</apiKey>
  <command>auth</command>
  <params>
    <username>%username%</username>
    <password>%password</username>
    [<persistent>1</persistent>]
  </params>
</cum>
 
====Params====
 
* '''%username%''' - Användarnamnet som skall kontrolleras.
* '''%password%''' - MD5-summa av lösenordet för användaren.
* '''persistent''' - Om given, talar om för API:et att skapa en [[svengelska|persistant]] session.
 
==== Returvärden ====
 
* <span style="color: #0a0;">''AUTH_SUCCESS''</span> - Både användarnamn och lösenord är korrekta, användare följer.
* ''AUTH_INVALID_PASSWORD'' - Användaren finns men lösenordet för denna användare är felaktigt.
* ''AUTH_INVALID_USERNAME'' - Användaren finns inte.
 
<h3 style="color: #c00;">userlist</h3>
 
Skickar förfrågan om en lista på alla användare och returnerar (oftast) en sådan lista. Eh.
 
==== Struktur ====
 
<cum>
  <apiKey>%apiKey%</apiKey>
  <command>userlist</command>
</cum>
 
==== Params ====
 
Uppenbarligen inga..
 
==== Returvärden ====
 
* <span style="color: #0a0;">''OK''</span> - Sessionen finns, användarlista följer.
 
<h3 style="color: #c00;">checksession</h3>
 
Kontrollerar ett sessionid mot databasen och returnerar, om det finns, en användare.
 
==== Struktur ====
 
<cum>
  <apiKey>%apiKey%</apiKey>
  <command>checksession</command>
  <params>
    <value>%sessionid</value>
  </params>
</cum>
 
==== Params ====
 
* '''%sessionid%''' - Ett sessionid, förmodligen hämtat från en kaka i en klientwebbläsare.


=== userlist ===
==== Returvärden ====
...


=== checksession ===
* ''NO_DATA'' - Sessionid:t finns inte.
...
* <span style="color: #0a0;">''OK''</span> - Sessionen finns, användare följer.


== Se även ==
== Se även ==

Versionen från 10 april 2006 kl. 08.38

CUM API är alltså API:et till CUM. Och tro det eller ej så finns det någon form av version av detta tillgängligt, redan. Denna sida samlar dokumentation av API:et så att godtycklig hacker kan hacka fram ett klientbibliotek.

Saker att komma ihåg

  • UTF-8-kodning
  • ...

Grundstruktur

Klient

Ett call till CUM's API ser ut såhär:

<cum>
  <apiKey>%apiKey%</apiKey>
  <command>%kommando%</command>
  <params>
    ...
  </params>
</cum>

Om man t.ex. vill kontrollera en användares användarnamn och lösenord mot API:et kan ett riktigt call se ut:

<cum>
  <apiKey>a3b4b2F2C2hg3ifs7</apiKey>
  <command>auth</command>
  <params>
    <username>användarnamn</username>
    <password>md5-summa-av-lösenord</password>
  </params>
</cum>

Server

Serversidans XML-svar är snarlikt, och är på formen:

<cum>
  <responseCode>%responseCode%</responseCode>
  
  [<result>
    ...
  </result>]
</cum>

Som svar på ovanstående klientsnutt skulle man t.ex. kunna få som svar:

<cum>
  <responseCode>102</responseCode>
</cum>

som talar om att lösenordet är felaktigt.

Kommandon

%apiKey% är rakt igenom din API-nyckel.

auth

Skickar en begäran om autentisering av en användare.

Struktur

<cum>
  <apiKey>%apiKey%</apiKey>
  <command>auth</command>
  <params>
    <username>%username%</username>
    <password>%password</username>
    [<persistent>1</persistent>]
  </params>
</cum>

Params

  • %username% - Användarnamnet som skall kontrolleras.
  • %password% - MD5-summa av lösenordet för användaren.
  • persistent - Om given, talar om för API:et att skapa en persistant session.

Returvärden

  • AUTH_SUCCESS - Både användarnamn och lösenord är korrekta, användare följer.
  • AUTH_INVALID_PASSWORD - Användaren finns men lösenordet för denna användare är felaktigt.
  • AUTH_INVALID_USERNAME - Användaren finns inte.

userlist

Skickar förfrågan om en lista på alla användare och returnerar (oftast) en sådan lista. Eh.

Struktur

<cum>
  <apiKey>%apiKey%</apiKey>
  <command>userlist</command>
</cum>

Params

Uppenbarligen inga..

Returvärden

  • OK - Sessionen finns, användarlista följer.

checksession

Kontrollerar ett sessionid mot databasen och returnerar, om det finns, en användare.

Struktur

<cum>
  <apiKey>%apiKey%</apiKey>
  <command>checksession</command>
  <params>
    <value>%sessionid</value>
  </params>
</cum>

Params

  • %sessionid% - Ett sessionid, förmodligen hämtat från en kaka i en klientwebbläsare.

Returvärden

  • NO_DATA - Sessionid:t finns inte.
  • OK - Sessionen finns, användare följer.

Se även