REST Standard per la modifica del modello SPA dopo essere stato recuperato dall'API REST

2

Immaginiamo. Ho i seguenti dati dal database.

======================================
id    |  Title     |   parentId
======================================
100      Asia          NULL
--------------------------------------
101      India         100
--------------------------------------
102      Tamil Nadu    101
--------------------------------------
103      Chennai       102
--------------------------------------
104      Karnataka     101
--------------------------------------
105      Bengalaru     104
--------------------------------------

Che può essere visualizzato come sotto il formato JSON. Tieni questo come primo formato.

{
  "children": [{
    "id": 100,
    "title": "Asia",
    "parentId": ""
  }, {
    "id": 107,
    "title": "India",
    "parentId": 100
  }, {
    "id": 108,
    "title": "Tamil Nadu",
    "parentId": 107
  }, {
    "id": 109,
    "title": "Karnataka",
    "parentId": 107
  }, {
    "id": 112,
    "title": "Chennai",
    "parentId": 108
  }, {
    "id": 113,
    "title": "Bengalaru",
    "parentId": 109
  }]
}

Mi piacerebbe avere sotto il formato JSON che è buono per il menu drill down ricorsivo e mantenere questo come secondo formato.

{
  "children": [{
    "id": 100,
    "title": "Asia",
    "children": [{
      "title": "India",
      "children": [{
        "title": "Tamil Nadu",
        "children":[{
          "title": "Chennai"
        }]
      }, {
        "title": "Karnataka",
        "children":[{
          "title": "Bengaluru"
        }]
      }]
    }, {
      "title": "China"
    }]
  }]
}

La mia domanda qui quale formato è REST Standard / best practice in REST. Utilizzando il primo formato e modificando tramite il modello JavaScript / utilizzando il secondo formato.

    
posta Venkat.R 22.01.2016 - 06:06
fonte

1 risposta

5

Né il formato è standard REST.

È la decisione della tua applicazione se utilizzare una rappresentazione gerarchica o una rappresentazione piatta o offrire entrambi, così come è la tua decisione se utilizzare JSON o XML o Protocol Buffers o HTML, o tutti, ad esempio.

Nessuna delle due rappresentazioni è la migliore pratica.

Dipende dalle esigenze delle tue applicazioni o dai bisogni dei tuoi clienti.

Non esiste davvero una taglia adatta a tutte le migliori pratiche per questo. Troverete una serie di opinioni. Ci sono potenzialmente ottime ragioni per farlo in entrambi i modi, a seconda delle tue esigenze, strumenti, competenze di squadra, ecc.

Devi solo considerare i pro e i contro nella tua situazione, e non preoccuparti troppo di ciò. Qualsiasi scelta funzionerà con la maggior parte degli strumenti.

Domande REST che dovresti fare

  1. Quali sono queste risorse? Come saranno gli identificativi delle risorse? (URI) Un modello URI semplice, efficiente e opportunamente memorizzabile nella cache è il cuore o il fondamento di un buon servizio REST. Come può un cliente specificare quale tipo di media, rappresentazione vuole?
  2. Dovrai recuperare più dettagli sui singoli stati (dell'India) e sulle capitali? Si tratta di una raccolta e sono stati dichiarati risorse individuali?
  3. Se l'applicazione dovrà GET o PUT, dì "Karnataka" come farà a sapere quale URI usare? Questo non è incluso nella tua rappresentazione.
  4. Se questa non è una risorsa di sola lettura, come utilizzeranno i comandi HTTP (GET, PUT, POST, ecc.) per agire su di essa? L'utilizzo corretto di questi comandi è al centro di REST su HTTP.
  5. Dopo, cerca HATEOAS. Quindi prendi un altro caffè. Leggi di nuovo, quindi posta qui le domande se necessario. Seriamente HATEOAS sembra lanciare le persone per un ciclo.
  6. Ora sei pronto per le guerre delle versioni. Come farai evolvere la tua API? Lo farai in versione? (Il REST pensava che la polizia mi avrebbe anche solo chiesto quella domanda).

Non esiste alcuna legge secondo cui le buone API devono utilizzare lo stile REST
Fielding è felice di ricordarcelo, se abbiamo bisogno di una voce rispettata.

Realmente fare REST è un impegno per alcuni sforzi intellettuali e una certa disciplina nel progettare, testare ed evolvere la tua API. Non è necessario per ogni API.

A volte devi solo costruire cose che funzionano e spedirle. Refactor sulla prossima iterazione quando ne sai di più.

    
risposta data 22.01.2016 - 08:38
fonte

Leggi altre domande sui tag