Canvis API

[PereBal]

Tot i que tenen bona pinta, @dobleme m'agradaria que exposasis una mica mes per què els vols realitzar i que guanyam amb ells.

[dobleme]

Bones, @PereBal,

T'explic un poquet els coneixements que em van transferir. En realitat els parametres no querystring a les uris tenen l'única ventatge semàntica. És a dir, en realitat són iguals que els paràmetres querystring.

El segón punt, és que seguint uns paràmetres REST, tenc entés que hauríem de fer accions sobre l'entitat. Per exemple, si enviam un missatge haurie, de fer un POST sobre l'url /messages. Sempre en plural. De tal manera les opcions són simplement afegits i no aporten valor semàntic.

Èstic a l'espera d'una pàgina que m'han dit que està de puta mare per entendre això del REST.

[PereBal]

Aquesta es la pàgina, gràcies per passar-la, la deix aquí per si algún dia la necessitam.

En resposta a les propostes:

Gráfics

GET / [Les altres propostes servirien per solicitar cada un dels gráfics en concret a la api, la gracia de '/' es dirigir al dashboard]

Admin

GET /admin 10/10 would bang :+1:

Chats

GET /chats[/:cid] realment el :cid es necessari? crec que si l'eliminam, tira milles GET /chats. POST /chats?party=uid no m'acaba de convencer, POST /chats/:cid [així reduim el nombre de rutes i té una mica mes de sentit tot, com és comenta aquí]? GET /chats/:cid/messages?unread=&begin= :+1: GET /chats[/:cid]?unread=, potser estaria més guay emprar GET /chats?unread=&skip=:cid POST /chats/:cid/message Si empram el POST /chats/:cid per obrir un nou xat, per mi ok. GET /users?value= :+1:

[dobleme]

GET /chats[/:cid] realment el :cid es necessari? crec que si l'eliminam, tira milles [GET /chats].

Això era per renderitzar amb un chat posat ja també... ho llevam?

POST /chats?party=uid no m'acaba de convencer, POST /chats/:cid [així reduim el nombre de rutes i té una mica mes de sentit tot, com és comenta aquí]?

No tenim el chat id, es el que generam... per això necessitam el user_id... que no es el mateix.

GET /chats[/:cid]?unread=, potser estaria més guay emprar GET /chats?unread=&skip=:cid

Això és per demanar un chat sencer... lo seu seria que hi hagues :cid, de fet hauria de ser obligaotori i no opcional.

POST /chats/:cid/message Si empram el POST /chats/:cid per obrir un nou xat, per mi ok.

Aixó crea un missatge associat a un chat evidentment... per axió l'anidació.

[PereBal]

GET /chats[/:cid]?unread=, potser estaria més guay emprar GET /chats?unread=&skip=:cid

Això és per demanar un chat sencer... lo seu seria que hi hagues :cid, de fet hauria de ser obligaotori i no opcional.

Aquesta funció no torna xats, aquesta funció torna:

 {
    "cid": {
      "count": "",
      "lmssg": ""
    }
  }

(En altres paraules, el contador de missatges no llegits i una preview del darrer missatge, l'opció skip era per evitar tornar el missatge de l'usuari amb 'focus').

POST /chats/:cid/message Si empram el POST /chats/:cid per obrir un nou xat, per mi ok.

Aixó crea un missatge associat a un chat evidentment... per axió l'anidació.

No home, deia que si empram el POST /chats/:cid Per obrir un nou xat, l'ús del: POST /chats/:cid/message té sentit

[dobleme]

GET /chats[/:cid]?unread=, potser estaria més guay emprar GET /chats?unread=&skip=:cid

Això és per demanar un chat sencer... lo seu seria que hi hagues :cid, de fet hauria de ser obligaotori i no opcional.

Aquesta funció no torna xats, aquesta funció torna:

Tota la rao del mon!! me pareix perfecte!!!

{[
    "cid": {
      "count": "",
      "lmssg": ""
    }
]}

Això hauría de ser així no?!

[PereBal]

Segons el que vulguis aconseguir. Tal qual ho has escrit està malament, les alternatives són:

• Llista de diccionaris:

[
    {
        "cid": "1",
        "count": "",
        "lmssg": ""
    },
    {
        "cid": "2",
        "count": "",
        "lmssg": ""
    }
]

Aquesta solució permet un accés sequencial ràpid, ideal per iterar.

• Emprar les claus com a entrades de diccionari:

{
    "1": {
        "count": "",
        "lmssg": ""
    },
    "2": {
        "count": "",
        "lmssg": ""
    }
}

Aquesta solució permet un accés sequencial i aleatòri amb un cost computacional una mica major.

Com que això ho empraran els de davant [@FranBisquerra @rafacuart @bcrespi @gbsantandreu] em pareix mes correcte que ells diguin quina estructura els serà més facil/óptima emprar.