intero progetto di consumo di servizi Web con php

Questo dipende dal livello di accoppiamento e dalla chiarezza dell'astrazione tra la GUI e il servizio web.

Le seguenti condizioni a livello di architettura sono necessarie per far funzionare le cose:

1. Le astrazioni degli elementi dei dati devono essere chiaramente ben definite. Inoltre, se lo scambio di dati è più vicino allo schema di DB sul lato del servizio Web, sarebbe più semplice. (se applicabile).
2. Il flusso degli scambi di messaggi deve essere articolato in modo molto chiaro. più è stateless, meglio è.
3. Il servizio Web dovrebbe avere NESSUNA conoscenza del modo in cui la GUI sta utilizzando i dati e non dovrebbe esserci alcuna logica specifica nell'implementazione del webservice. Ad esempio, a seconda della vista corrente o dell'ultima query, il web service non dovrebbe fare calcoli.
4. È meglio che le sessioni di front-end Web siano tenute lontane dal servizio o limitate; meccanismi come l'autenticazione dovrebbero essere basati su broker indipendenti (come OpenID) o essere schermati tra User to GUI vs. GUI al servizio Web.
5. Le regole aziendali sono ben documentate e concordate.
6. Applicazione della crittografia dei messaggi, se applicabile.

In generale, prova a progettare API di servizi Web in modo tale che almeno due diversi tipi di GUI potrebbero aver bisogno di usarlo senza dover eseguire comportamenti inconsistenti. (questo ti aiuta a prendere coscienza dell'accoppiamento specifico della GUI).

Quanto sopra sono le regole di base per qualsiasi piattaforma. A parte questo, dal momento che hai menzionato, che questo è un matrimonio tra .NET e PHP, proverei a giocare in sicurezza e comunicare solo usando puro XML . Quindi suppongo che il REST o anche il semplice vecchio XML RPC possano funzionare molto meglio di SOAP. Non è che SOAP non possa funzionare - ma immagino che non sarà senza problemi rispetto alla comunicazione "plain XML".

Dipan.

Penso che tu abbia semplificato le descrizioni delle tue idee e, quindi, è difficile per me capire cosa intendi per loro. Detto questo, questo è il modo in cui mi sembra che tutto questo si avvicini.

• Disegna una API di comunicazione per il loro servizio. Che cosa è reale il protocollo di trasferimento è meno importante, concentrarsi su ciò che le chiamate sono e le strutture dati necessarie.
• Presenta l'api al tuo partner. Raggiungi un accordo e finalizza l'API e il protocollo di trasferimento.
• Sono incaricati di implementare l'API e tu sei responsabile di tutto il lavoro di visualizzazione per presentare i dati.

Il beneficio dell'API chiaramente definita è che puoi eseguire il tuo lavoro prima che forniscano l'implementazione del servizio. Puoi scrivere test che utilizzano un'implementazione fittizia per assicurarti di gestire i dati correttamente in base alla API definita.

Ci sarà sempre qualcosa che rende l'integrazione più interessante di quanto speravi, ma la chiara linea di divisione e i modi definiti di attraversare quella linea ti permettono di sviluppare e testare il tuo codice nel tentativo di minimizzare i problemi con l'integrazione.