Perché questa API include un parametro "tipo" statico nella richiesta e nella risposta?

Question

Perché questa API include un parametro "tipo" statico nella richiesta e nella risposta?

#1 da (1 voti)

0

Sto osservando l'API Google QPX Express e ho notato che ogni gruppo di parametri include un parametro kind impostato su una stringa specifica. Ad esempio, sulla richiesta:

{
  "request": {
    "passengers": {
      "kind": "qpxexpress#passengerCounts",
      "adultCount": integer,
      "childCount": integer,
      "infantInLapCount": integer,
      "infantInSeatCount": integer,
      "seniorCount": integer
    },
    "slice": [
      {
        "kind": "qpxexpress#sliceInput",
        "origin": string,
        "destination": string,
        "date": string,
        "maxStops": integer,
        "maxConnectionDuration": integer,
        "preferredCabin": string,
        "permittedDepartureTime": {
          "kind": "qpxexpress#timeOfDayRange",
          "earliestTime": string,
          "latestTime": string
...

La risposta include anche kind :

{
  "kind": "qpxExpress#tripsSearch",
  "trips": {
    "kind": "qpxexpress#tripOptions",
    "requestId": string,
    "data": {
      "kind": "qpxexpress#data",
      "airport": [
        {
          "kind": "qpxexpress#airportData",
          "code": string,
          "city": string,
          "name": string
...

Qual è il punto di questo parametro? Questo tipo di cose è importante da includere in un'API ben progettata?

api-design rest

posta drs 13.02.2015 - 21:45

fonte

1 risposta

Leggi altre domande sui tag api-design rest

Utilizzo di "bugfix" per fare riferimento alle modifiche dell'interfaccia utente nei nomi dei rami L'uso delle firme digitali e delle macchine bytecode è una tecnica praticabile per rendere difficile il reverse engineering? [duplicare]

score 1 · Answer 1

All'interno della richiesta e della risposta che hai inviato non ha senso, ma darò un esempio più semplice. Immaginiamo di avere un sistema di ordinazione della pizza, che ci permette di ordinare le pizze (con guarnizioni extra) o le bibite (potenzialmente super-dimensionate). Per implementare il nostro servizio, potremmo formattarlo in questo modo:

{
    drinks: [{ brand: 'pipsi', size: 'large'}, { brand: 'cako loca', size: 'small' }],
    pizzas: [{ name: 'peperoni', toppings: 'mozarella'}]
}

tuttavia, questo diventa rapidamente ingombrante quando disponiamo di molti tipi di pizza, bevande, dessert, ecc. ecc. Invece, vogliamo dare un po 'di classe alla nostra piccola API. Potremmo classificare ciascuno di questi in due tipi diversi: "PizzaData" e "SoftDrinkData".

Ora le parti del nostro ordine possono essere ordinate in qualsiasi ordine e abbiamo persino la possibilità di aggiungere versioni della nostra API a sottoparti specifiche. È anche più facile spezzare il nostro messaggio e inviarlo a luoghi separati e fare in modo che quei luoghi capiscano come gestirlo. Vediamo come appare ora:

[
   { kind: 'SoftDrinkData', brand: 'pipsi', size: 'large' },
   { kind: 'SoftDrinkData', brand: 'cako loca', size: 'small' },
   { kind: 'PizzaData', name: 'peperoni', toppings: 'mozarella' }   
]

Se i nostri processori di dati introdurranno un nuovo tipo di pizza (ad esempio, puoi specificare la forma), puoi aggiungere una versione aggiuntiva:

[ { kind: '[email protected]', name: 'Quatro Stagioni', 
    toppings: 'salami', shape: 'triangular' } ]

I vecchi sistemi ora inizieranno a lamentarsi perché non sanno come gestire '[email protected]'. Sarebbe bello, dal momento che non vuoi che il cliente ottenga una pizza rotonda. Ha ordinato uno triangolare dopo tutto. Tuttavia, tutti gli altri dati possono ancora essere elaborati, quindi possiamo mescolare insieme vecchi e nuovi sistemi e non abbiamo un momento di "big bang" quando una nuova versione dell'API viene fuori.

La maggior parte delle librerie JSON mappano i dati JSON alle istanze di classi di un linguaggio orientato agli oggetti. La libreria deve sapere a quale classe mappare, quindi aggiungere questi dati extra aiuta la libreria a mapparla sulla classe giusta, invece di fare affidamento sulla posizione all'interno dell'albero JSON.