2015-08-07 7 views
9

Desidero creare un'applicazione Laravel 5.1 per web e API per le app mobili. Voglio restituire JSON per richiesta API e visualizzare per browser web. Attualmente ho impostato percorsi diversi e controller diversi. In questo approccio sto ripetendo il codice. Non so quale sia l'approccio migliore per progettare questa architettura. Inoltre, ho attraversato alcuni thread simili che raccomandano l'uso di angular.js per il browser web.Come progettare l'applicazione laravel 5.1 per client Web e app mobili native

// web controller 
Route::resource('product', 'ProductController'); 

// api controller 
Route::group(['prefix' => 'api'], function() { 
    Route::resource('product', 'APIProductController'); 
}); 
+0

Non so che tempo sia applicabile in laravel o meno, ma possiamo creare gruppi/spazi dei nomi in Rubyonrails per lo scopo prefissato. Controlla questo http://laravel-tricks.com/tricks/route-group-namespacing –

risposta

1

Un modo sarebbe utilizzare l'approccio content negotiation. Dovresti passare l'intestazione Accept: application/json e l'app restituirà la risposta in formato json. tuttavia alcuni server proxy non rispettano la negoziazione del contenuto, quindi la tua app si interromperà (puoi leggere di più perché Drupal ha abbandonato la negoziazione del contenuto here).

Un'altra possibilità è usare tu qualche variabile GET per tornare formato richiesto, ad esempio: /api/product?format=json

Inoltre è possibile passare variabile da /api chiamate:

Route::get('/api/product', ['as' => 'product', function(){ 
    return App::make('ProductController')->index('json'); 
}]); 

public function index($format) { 
    // Your controller code 

    if ($format == 'json') { 
     // return JSON 
    } 

    // return HTML 
} 

Oppure si può analizzare URI direttamente e vedere se inizia con /API (non è consigliabile). Le mie scelte sarebbero la negoziazione del contenuto o/e la variabile GET format.

+0

Beh, posso modificarlo in questo modo, ma voglio farlo il più ordinatamente possibile concentrandomi sulla progettazione di un'architettura migliore – Ashish

+0

prova dingo/api è pulito e supporta il controllo delle versioni, la maggior parte dei metodi di autenticazione. – astroanu

2

Si possono avere 2 approcci di base:

  • Tenere percorsi e controller separati, ma spostare tutto il codice del controller comune in un servizio. Questa è probabilmente la soluzione più pulita e più flessibile, in quanto rende molto semplice aggiornare i metodi API e Web in modo indipendente in futuro.
  • Oppure è possibile instradare entrambe le richieste API e Web allo stesso controller, passare l'oggetto Request in esso e, in base ad alcuni attributi, decidere quale risposta restituire, json o html.

Per il secondo approccio si potrebbe per esempio fare in questo modo:

// web controller 
Route::resource('product', 'ProductController'); 

// api controller 
Route::group(['prefix' => 'api'], function() { 
    Route::resource('product', 'ProductController'); 
}); 

// and in the ProductController you have 
public function index(Request $request) 
{ 
    // do some stuff... 

    if ($request->segment(1) === 'api') { // route prefix was api 
     // return json 
    } else { 
     // return the view 
    } 
} 

Si potrebbe anche utilizzare il metodo $ request-> wantsJson() per verificare Accept: intestazione o si poteva passare un GET speciale variabile (es. ?_format=json) con tutte le chiamate API per definire il formato di risposta dovrebbe essere json, come già suggerito da @Bogdan Kuštan. IMHO se usi già il prefisso API sui tuoi url è più affidabile e più pulito controllarlo.

+0

Grazie a @ivanhoe. Sto usando un modello di progettazione del repository, spostando la mia logica comune lì. Al controller, digita l'interfaccia e accedi ai metodi comuni. – Ashish