2012-07-27 19 views
5

Quindi, ho letto molto su SOA ultimamente e ho cercato di implementare qualcosa di utile. Ho iniziato con un semplice blog, creando l'API RESTful. Fin qui tutto bene. Funziona perfettamente. Tuttavia, sto iniziando a strapparmi i capelli quando scrivo l'interfaccia web che consumerà l'API RESTful. Non so se sto facendo la cosa giusta.Approccio SOA RESTful corretto nelle applicazioni PHP?

Ad esempio, l'interfaccia web ha un pannello di amministrazione. Quel pannello di amministrazione fa richieste HTTP all'API, attraverso file_get_contents e opzioni di streaming. In questo momento, l'API è localhost, così come l'interfaccia web, ma l'intero processo è un po 'più lento. È giusto? È questo il modo corretto di implementare un SOA? Inoltre, ho a che fare con piccoli bit di codice duplicato per la convalida. Dove devo convalidare i dati? Nell'API o nell'interfaccia web? Qual è l'approccio migliore?

Consigli, tutorial e, soprattutto, i libri sono i benvenuti. Questo è stato implementato usando Silex, costruito su componenti Symfony.

+1

Sto solo pensando ad alta voce qui. L'interfaccia Web è ospitata tramite localhost, quindi l'API che si trova sul server non cambia molto, tranne che il numero di richieste aumenta in genere e non c'è Internet da attraversare. Il tuo computer sta riagganciando la richiesta prima ancora che lasci la scheda di rete. Altri spunti di riflessione. Se l'API ha qualche utilità al di fuori di servire le tue pagine web, allora creerei la convalida dei dati nell'API. In questo modo puoi rilasciare agli utenti sia l'API stessa che il sito web. – Kevin

risposta

1

Questo è esattamente come lo faccio. Anche se la connessione con localhost potrebbe sembrare un sovraccarico in un primo momento, è una funzionalità, dal momento che sei pronto a distribuire la tua applicazione di interfaccia web ovunque e continua a utilizzare la tua API, che potrebbe essere ovunque. Ovviamente, potresti mettere un po 'di SSL su questo.

Per quanto riguarda la convalida, è necessario convalidare l'API e restituire HTTP status codes per tali situazioni (ad esempio, "400 Richiesta non valida" per i parametri non validi). In questo modo, qualsiasi altro client può interpretare la risposta dall'API e trattarla per mostrare come vogliono. Nel caso della tua interfaccia web, piccoli messaggi di errore piacevoli basati sul codice di stato HTTP.

Quali altri problemi stai affrontando? Inoltre, per quanto riguarda l'architettura SOA generale, this book è molto buono.

+0

Sebbene io sia d'accordo in linea di principio, se tu sai che la tua API si trova nella stessa casella del tuo frontend, dovresti provare a chiamarla all'interno della stessa esecuzione per salvare i costi di connessione delle risorse e delle connessioni bootstrap. Ovviamente il passaggio tra locale e remoto dovrebbe, dove possibile, essere senza soluzione di continuità. L'utilizzo di un oggetto client per astrarre questo potrebbe ottenere ciò. –