Le migliori pratiche per restituire json in un'applicazione REST?

2

Sto iniziando ora con le applicazioni REST (usando Laravel 4.2) e Mobile (Android, iOS, SP, ecc.).

Inizialmente sto controllando se la richiesta è ajax / json e poi restituisco una risposta json.

Ma questa condizione è in una normale azione (HTTP), quindi:

se ajax / json restituisce json, else restituisce la vista / template / layout

È corretto farlo nella stessa azione, o è la procedura migliore per creare un altro controller per quello? Ad esempio:

  • PostsController
  • PostsMobileController

o

  • PostsController
  • Mobile \ PostsController (o Json \ Controller) - utilizzando spazi dei nomi
posta Patrick Maciel 25.07.2014 - 14:36
fonte

2 risposte

3

Sebbene la soluzione giusta dipenda dal tuo contesto, ecco il mio approccio:

Durante la progettazione delle classi si dovrebbe sempre considerare la loro singola responsabilità . Nel caso del PostsController potrebbe probabilmente essere descritto "creare, leggere aggiornare ed eliminare" i post. La formattazione dell'output è un problema globale dell'applicazione che non dovrebbe essere risolto singolarmente in ogni controller. Meglio sarebbe progettarlo come una strategia / aspetto dell'output / qualunque sia il linguaggio e il framework che consente.

Immagina se hai bisogno di un'API per l'output di XML in un dato momento. Creeresti davvero nuovi controller per ogni entità?

Btw, quando considero tali domande (per qualsiasi lingua) tendo a guardare la documentazione di Rails , che ha un bel approccio qui:

class UsersController < ApplicationController
  def index
    # Load all users
    @users = User.all
    # Different formattings based on request headers
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render xml: @users}
      format.json { render json: @users}
    end
  end
end
    
risposta data 25.07.2014 - 15:32
fonte
1

Hai delineato i due approcci principali e ognuno di essi ha i suoi vantaggi e svantaggi.

Se si combinano entrambi nello stesso controller e tutto ciò che si sta facendo è cambiare l'output, quindi usare un singolo controller ha senso. La logica è la stessa, ma l'output cambia.

Se la logica deve cambiare perché l'output è diverso, quindi utilizzare due controller diversi.

Separarli in due controller ti dà anche la possibilità di aggiungere facilmente il supporto per le piattaforme non web, ad es. applicazioni mobili native. La tua app Larvel ha quindi due lati: il lato web e un'API dati.

La direzione che prendi dipenderà in gran parte dalle esigenze future dell'applicazione. Il mio consiglio è di iniziare in modo semplice. Utilizzare un singolo controller che cambia solo il formato di output. È più facile aggiungere la complessità più tardi di quanto non lo sia aggiungere semplicità. Se hai bisogno di un'API dati in un secondo momento, inizia ad aggiungere controller diversi dopo aver eseguito alcune operazioni di progettazione di architettura e sistema.

    
risposta data 25.07.2014 - 15:25
fonte

Leggi altre domande sui tag