json-rpc smd

[lab@nohl]

Hallo,

wer kennt sich mit dem JSON-Zeug so aus, dass er was Allgemeines darüber sagen kann? Mit "allgemein" meine ich unabhängig von PHP/Zend.

Ich verstehe, dass ich Fragen stelle, indem ich von index.php?method=Modul.Funktion via GET-Request einen JSON-Response hole. Antworten tue ich mit POST-Request an die gleiche URL.

Soweit so gut. Jetzt würde ich aber gerne eine Art SMD-Browser schreiben, der mir hilft die Funktionen zu erkunden. Scheitert schon am SMD. Laut Wiki soll der "request-type" auf "application/json-rpc" gesetzt sein.

Problem 1: Ich kenne keinen HTTP-Header "request-type". Ich kenne nur "Content-Type".

Problem 2: HTTP-Method soll NULL sein. Ich kenne POST, GET, OPTIONS usw., aber NULL kenne ich nicht. Ich kann sehen, dass ein leerer String übertragen werden kann, das wird dann UNKNOWN genannt; ist das identisch mit NULL?

Problem 3: Bei welcher URL bekomme ich den SMD? Einfach an index.php oder muss es irgendwas wie index.php?json-smd sein?

Proble 4: Gibt es weitere Mindestvoraussetzungen? Wie einen "Accept: json-rpc" Header?!

Jede Anfrage, die nicht mit GET oder POST an index.php geht, liefert bei mir einen leeren Body zurück.

Danke für jede Form der Hilfe! Wenn ich es hinbekomme würde ich als Gegenleistung das Wiki entsprechend ergänzen.

[lkneschke]

Prinzipiell verwendet Tine 2.0 immer POST Requests für die JSON Kommunikation. Entscheidend ist das es einen POST oder GET Parameter gibt der method heißt.

Zu 1.)
Tine 2.0 verwendet einen POST Parameter requestType=JSON Parameter um einen JSON Request zu erkennen. Alternativ geht auch der Header Content-Type='application/json.*'.

Siehe Tinebase/Core.php

Code: Select all

/**************************** JSON API *****************************/
if ( (isset($_SERVER['HTTP_X_TINE20_REQUEST_TYPE']) && $_SERVER['HTTP_X_TINE20_REQUEST_TYPE'] == 'JSON')  ||
            (isset($_SERVER['CONTENT_TYPE']) && substr($_SERVER['CONTENT_TYPE'],0,16) == 'application/json')  ||
            (isset($_POST['requestType']) && $_POST['requestType'] == 'JSON')
) {
    $server = new Tinebase_Server_Json();

Zu 2.)
Mit Method ist der POST oder GET Parameter method gemeint.

Siehe Tinebase/Server/Json.php

Code: Select all

if(empty($method)) {
    // SMD request
    return self::getServiceMap();
}

Zu 3.)
Einfach an index.php posten.

Zu 4.)
Ich glaube nicht.

Ansonsten schau Dir doch noch mal http://www.tine20.org/wiki/index.php/De ... r_JSON-RPC an. Das fragt auch die SMD ab. Wenn Du den Traffic z.B. mit Wireshark mitschneidest, kannst Du ganz genau sehen was hin- und hergeschickt wird.

[lab@nohl]

[...Zeitreise...]

Ok, grundsätzlich habe ich das soweit hinbekommen. Ich kann mich an- und abmelden. Folgende Fragen haben sich noch ergeben:

1) Wenn man mit method null den ServiceMap abfragt, hat der sowohl die Einträge "methods" als auch "services", die zumindest auf den ersten Blick den gleichen Inhalt haben. Was brauche ich für was? Oder anders gefragt: Was soll das?

Code: Select all

{
    "transport": "POST",
    "envelope": "JSON-RPC-2.0",
    "contentType": "application/json",
    "SMDVersion": "2.0",
    "target": "index.php",
    "services": { … },
    "methods": { … }
}

2) Wie kann man den "vollständigsten" SMD bekommen? Als Admin anmelden? Oder bekommt jeder Nutzer alle methods angezeigt?

3) Was ist mit den methods/services, die mit "Tinebase_" anfangen? Warum sind die nicht unter "Tinebase." angesiedelt?

[nelius]

1. Das ist das gleiche, so purzelt das aus unerfindlichen Gründen aus der Zend_Json_Server. Der Zend_Json_Client braucht es dann aber auch wieder.

2. Man bekommt immer nur die SMD für die Sachen / Apps zu denen man Zugang hat.

3. Der Übersicht halber

[lab@nohl]

3. Der Übersicht halber

Das verstehe ich leider nicht wirklich. Warum ist es übersichtlicher, einzelne Methoden von ihrem Controller zu trennen? Diese Methoden haben keine besondere Funktion? Für mich wirkt es eher, als seien Methoden, die mit Tinebase_ beginnen auch ohne Anmeldung erreichbar?

Frage:

Wie kann ich das Gerüst für einzelne Parameter herausfinden? Wie sieht etwa die Struktur für regData (registerUser) oder recordData (saveContact bzw. saveEvent) aus?

Code: Select all

Tinebase_UserRegistration.registerUser": {
    "envelope": "JSON-RPC-2.0",
    "transport": "POST",
    "parameters": [
        {
            "type": "array",
            "name": "regData",
            "optional": false
        }
    ],
    "returns": "boolean"
}

oder

Code: Select all

Addressbook.saveContact": {
    "envelope": "JSON-RPC-2.0",
    "transport": "POST",
    "parameters": [
        {
            "type": "array",
            "name": "recordData",
            "optional": false
        }
    ],
    "returns": "array"
}

oder

Code: Select all

Calendar.saveEvent": {
    "envelope": "JSON-RPC-2.0",
    "transport": "POST",
    "parameters": [
        {
            "type": "array",
            "name": "recordData",
            "optional": false
        },
        {
            "type": "boolean",
            "name": "checkBusyConficts",
            "optional": true,
            "default": false
        }
    ],
    "returns": [
        "array",
        "array"
    ]
}

Ich stell mir das gewissermaßen so vor, dass ich eine leere JSON-Struktur habe und diese dann mit Werten an den entsprechenden Stellen auffülle. Und das dann mit der entsprechenden Funktion an das Backend übergebe. Ich nehme mal an, dass macht das Javascript auch, oder?

[nelius]

Leider sind die Models noch nicht selbstbeschreibend. Du musst dir die Properties aus den entsprechenden PHP holen <Appname>/Model/<Modelname>.php

Zusätzlich ist ein Tool wie Firebug od. Webinspector gut geeignet um dir die Kommunikation des Web-Clients anzusehen.

[lab@nohl]

Zusätzlich ist ein Tool wie Firebug od. Webinspector gut geeignet um dir die Kommunikation des Web-Clients anzusehen.

Ja klar, so habe ich das jetzt auch gemacht. Wahrscheinlich müsste ich mir einfach mal das Javascript näher ansehen. D.h. aber auch, dass das Frontend keine Informationen darüber hat, welche properties verpflichtend sind, es muss es halt wissen.

Was hat es eigentlich mit den Containern auf sich? Ist ein Container die Abstraktion für Gruppe, Adressbuch, Kalender usw.? Was sind Persistents?

Hat die Methode Ping eigentlich eine Funktion?

[ph_il]

Was hat es eigentlich mit den Containern auf sich? Ist ein Container die Abstraktion für Gruppe, Adressbuch, Kalender usw.?

genau. jeder record liegt in einem container (ausnahmen: emails, stundenzettel), an dem auch die zugriffsrechte festgemacht sind.

Was sind Persistents?

du meinst wahrscheinlich "persistent filter". das ist das gleiche wie favoriten. das sind die filter, die man sich selbst abspeichern kann, bzw. die für jede app vorgegeben sind.

Hat die Methode Ping eigentlich eine Funktion?

hm, das ist ganz alter code. ich glaube, die wird nicht mehr gebraucht.

[lab@nohl]

Ich hätte noch ein paar Fragen, wie man einen Termin einträgt, bevor ich das alles umsetze. Zur Illustration habe ich die Request-Parameter unten angehängt.

1) Ist "checkBusyConficts" eigentlich ein Schreibfehler?

3) Müssen immer alle Felder übergeben werden (z.B. "creation_*", "last_modified_*", "deleted_*", "id" etc.) - einige werden doch (hoffentlich) vom Server überschrieben?

3) Warum wird bei "container_id" eigentlich der gesamte Kalendar-Container übergeben? Buchstäblich müsste doch lediglich die id (hier 2310) ausreichen?

4a) Ähnlich wie bei 3) der "organizer", mir scheint auch das ein gesamter (interner) Adressbucheintrag zu sein. Reicht da nicht auch die Id?

4b) "attendee" ist ein Array, der Organizer das erste Member. Welche "user_type" gibt es? Reicht es im Falle von "user" nicht, bei "user_id" die Id statt des ganzen Accounts zu übergeben?

5) Verständnisfrage: Wie stelle ich wiederkehrende Events mit Ausnahmen her? In welchem Zusammenhang steht da "recurid" und "exdate" (offensichtlich ein Array, mit Datum/Startzeit). Welche "rrule" gibt es, welche weiteren parameter kennen sie?


Besonders die letzte Frage wäre mir wichtig, ich würde mich über eine Antwort freuen.

Code: Select all

"recordData": {
    "container_id": {
        "id": "2310",
        "name": "Test",
        "type": "personal",
        "backend": "Sql",
        "color": "#FF00FF",
        "application_id": "2fc3822724df1e7defbf1c5ca214fb587e03b5ba",
        "created_by": "4928b5e3232cfe053a76a31d07e4a11416ee9566",
        "creation_time": "2011-10-22 22:57:38",
        "last_modified_by": null,
        "last_modified_time": null,
        "is_deleted": "0",
        "deleted_by": null,
        "deleted_time": null,
        "account_grants": {
            "readGrant": true,
            "addGrant": true,
            "editGrant": true,
            "deleteGrant": true,
            "privateGrant": true,
            "exportGrant": true,
            "syncGrant": true,
            "adminGrant": true,
            "freebusyGrant": true,
            "account_id": "4928b5e3232cfe053a76a31d07e4a11416ee9566",
            "account_type": "account"
        },
        "is_container_node": false
    },
    "creation_time": "",
    "created_by": "",
    "last_modified_time": "",
    "last_modified_by": "",
    "is_deleted": "",
    "deleted_time": "",
    "deleted_by": "",
    "id": "",
    "dtend": "2012-01-02 19:00:00",
    "transp": "OPAQUE",
    "class": "PUBLIC",
    "description": "",
    "geo": "",
    "location": "",
    "organizer": {
        "id": "4",
        "adr_one_countryname": null,
        "adr_one_locality": null,
        "adr_one_postalcode": null,
        "adr_one_region": null,
        "adr_one_street": null,
        "adr_one_street2": null,
        "adr_two_countryname": null,
        "adr_two_locality": null,
        "adr_two_postalcode": null,
        "adr_two_region": null,
        "adr_two_street": null,
        "adr_two_street2": null,
        "assistent": null,
        "bday": null,
        "calendar_uri": null,
        "email": "",
        "email_home": null,
        "freebusy_uri": null,
        "geo": null,
        "note": null,
        "container_id": "2",
        "pubkey": null,
        "role": null,
        "room": null,
        "salutation_id": null,
        "title": null,
        "tz": null,
        "url": null,
        "url_home": null,
        "n_family": "user",
        "n_fileas": "user, demo",
        "n_fn": "demo user",
        "n_given": "demo",
        "n_middle": null,
        "n_prefix": null,
        "n_suffix": null,
        "org_name": null,
        "org_unit": null,
        "tel_assistent": null,
        "tel_car": null,
        "tel_cell": null,
        "tel_cell_private": null,
        "tel_fax": null,
        "tel_fax_home": null,
        "tel_home": null,
        "tel_other": null,
        "tel_pager": null,
        "tel_prefer": null,
        "tel_work": null,
        "created_by": "05ba52b53189ca9d4d8caf42baac9beb0b15b976",
        "creation_time": "2009-07-21 10:41:25",
        "last_modified_by": null,
        "last_modified_time": null,
        "is_deleted": "0",
        "deleted_by": null,
        "deleted_time": null,
        "lon": null,
        "lat": null,
        "type": "user",
        "jpegphoto": "0",
        "account_id": "4928b5e3232cfe053a76a31d07e4a11416ee9566"
    },
    "priority": "",
    "status_id": "",
    "summary": "Testtermin",
    "url": "",
    "uid": "",
    "attendee": [
        {
            "user_type": "user",
            "role": "REQ",
            "quantity": 1,
            "status": "ACCEPTED",
            "user_id": {
                "accountId": "4928b5e3232cfe053a76a31d07e4a11416ee9566",
                "accountLoginName": "tine20demo",
                "accountLastLogin": "2012-01-02 15:53:08",
                "accountLastLoginfrom": "91.66.77.28",
                "accountLastPasswordChange": "2009-07-21 10:41:25",
                "accountStatus": "enabled",
                "accountExpires": null,
                "accountPrimaryGroup": "c86d1e3f2d879837c95d5ba65c052aea279c77e1",
                "accountHomeDirectory": "",
                "accountLoginShell": "",
                "accountDisplayName": "user, demo",
                "accountFullName": "demo user",
                "accountFirstName": "demo",
                "accountLastName": "user",
                "accountEmailAddress": "",
                "lastLoginFailure": "2011-10-25 17:26:13",
                "loginFailures": "0",
                "contact_id": "4",
                "openid": null,
                "visibility": "displayed",
                "container_id": "2"
            }
        }
    ],
    "alarms": "",
    "tags": [ ],
    "notes": [ ],
    "dtstart": "2012-01-02 18:00:00",
    "recurid": "",
    "exdate": "",
    "rrule": "",
    "is_all_day_event": false,
    "rrule_until": "",
    "originator_tz": "",
    "readGrant": false,
    "editGrant": true,
    "deleteGrant": false

},
"checkBusyConficts": 1


[ph_il]

1) jo, habe ich im git master behoben.

2) es müssen nicht alle übergeben werden. die "modlog" felder werden sowieso vom server gesetzt. die id ist allerdings wichtig, da wir daran festmachen, ob wir einen neuen eintrag haben oder ob es sich um ein update handelt.

3) + 4) es sollte in den meisten fällen reichen (ganz sicher bin ich mir nicht), die id zu übergeben. wir haben das da in "aufgelöster" form, damit wir alle infos (namen, typ, ...) im client anzeigen können. am besten einfach ausprobieren, was passiert, wenn man nur die id zurückgibt.

4b) es gibt noch folgende teilnehmertypen (aus Calendar_Model_Attender):

Code: Select all

/**
     * supported user types
     */
    const USERTYPE_USER        = 'user';
    const USERTYPE_GROUP       = 'group';
    const USERTYPE_GROUPMEMBER = 'groupmember';
    const USERTYPE_RESOURCE    = 'resource';
    const USERTYPE_LIST        = 'list';

5) das muss dir wohl cornelius beantworten ...