Quali sono alcune delle insidie ​​/ suggerimenti che si potrebbero dare per lo sviluppo di un servizio web

Question

Cercare di sviluppare un servizio Web (api) in PHP per offrire ai clienti un modo più semplice per integrarsi con la nostra piattaforma. Vi sono chiamate del flusso di lavoro che verranno convalidate con user/pass e alcune opzioni di reporting.

Mi spiace non posso pubblicare ulteriori dettagli o codice sull'argomento e non ho mai sviluppato un servizio web ma ho avuto esperienza nell'usarli tramite SOAP.

Ora avrei anche bisogno di offrire uno stato o stato del flusso di lavoro e penso che REST sarebbe la scelta migliore qui, ma ancora in cerca di opinioni su questo.

Per la segnalazione Vorrei offrire diverse opzioni come XML, Excel/CSV, qualsiasi motivo ne sceglierei uno sull'altro?

Quali sono alcune delle insidie ​​che dovrei cercare?

Quali sono alcune gemme che chiunque potrebbe offrire.

Grazie in anticipo a qualsiasi aiuto in quanto è molto importante per me capire.

UPDATE # 1:

• Quale sarebbe il metodo più sicuro?
• Qual è il metodo più flessibile (indipendente dalla piattaforma)

UPDATE # 2: un po 'sul flusso di dati. Ogni utente ha creds per utilizzare l'API e nessun dato è condiviso tra gli utenti. L'utilizzo è inviare una richiesta, la richiesta viene elaborata e viene restituito un reso. nessun aggiornamento. (Pensa a Google) viene effettuata una richiesta di ricerca e vengono forniti i risultati, ma nel mio caso viene fornito solo un risultato. Non so se questo è necessario quindi è una FYI.

Answer 1

Always handle errors and exceptions. 

I problemi faranno sempre sentire la loro presenza nell'applicazione/api. O all'inizio o attraverso ulteriori sviluppi. Non lasciare questo come attività finale e chiarire quando si verifica un errore, con messaggi di risposta ben documentati.

Inoltre, se il servizio gestirà molte richieste e per lo stesso ID risorsa (indipendente dall'utente) viene restituita la stessa risorsa, assicurarsi di memorizzare nella cache le informazioni. E questo non solo per motivi di prestazioni, ma per i casi in cui gli errori si sono bloccati. In questo modo puoi almeno servire qualcosa al cliente (probabilmente utile, più contesto richiesto per essere esplicito).

Answer 2

L'elemento più grande e più importante che posso offrire è quello di garantire la tua infrastruttura dietro il WS o almeno quello che stai servendo tramite il WS è senza stato. Nel momento in cui dividi questo diventerà un incubo e inizierai a dover inserire il codice calzato per proteggere i tuoi dati da rischi.

Un esempio potrebbe essere un due client che apporta modifiche ai dati tramite WS, ad esempio ... salva la configurazione. Il modo in cui lo gestisci nel back-end rende le cose interessanti. Se i tuoi dati si stanno dirigendo solo in uscita, ti trovi in ​​una situazione molto migliore se devi supportare lo spingere i dati nel back-end.

Inoltre, pensa in profondità all'API come con qualsiasi API pubblica. Nel momento in cui disponi di una versione in sospeso e poi decidi che l'API deve essere modificata o deprecata inizia a causare problemi per il client che utilizza il tuo WS.

Answer 3

Attualmente sto lavorando a un'applicazione Web che include un servizio Web (o 2 in ASP.NET MVC) e consiglio vivamente di osservare i principi alla base dell'architettura orientata ai servizi (SOA) come quello che ho trovato è che il più Un aspetto importante è quello di rendere corretto il design dell'API del servizio web in modo tale da influenzare il resto del back-end e rendere la vita più facile o farti sbattere contro i muri per la frustrazione.

Essenzialmente SOA significa progettare il servizio Web intorno ai processi aziendali, cioè come le persone che usano la tua API potrebbero usarlo.

Un buon desgin è sempre una buona idea, quindi consiglio vivamente di leggere molto su Web Sevice Design Principles prima di iniziare a programmare e salvare te stesso o qualche altro sfortunato sacco di dolore.

Assicurati anche che il tuo design sia agile in quanto cambierà frequentemente mentre avviene la comunicazione tra la tua azienda e i tuoi clienti.

Answer 4

Un po 'più relativo all'implementazione rispetto alla progettazione: Deciderei che l'output del servizio sia XML - questo può essere analizzato molto facilmente, con tutte le lingue decenti. Inoltre, se alcuni client necessitano di un altro output, è possibile trasformare tali XML tramite alcuni processori XSLT e offrire "altri" servizi Web, che emettono JSON o qualsiasi altra cosa di cui hanno bisogno. Per quanto riguarda il reporting, ciò dipende da come verranno utilizzati i report - se i client li elaborano e hanno bisogno solo dei dati dai report - quindi di nuovo suggerire XML. Secondo me lavorare con CSV è più difficile perché devi prendere in considerazione tutti i tipi di casi speciali come "cosa succede se i miei dati contengono il campo separatore", "il client sarà in grado di specificare il separatore", "come rappresenterò dati annidati "o tutti questi sono semplici con XML. Se il tuo cliente ha bisogno di rapporti per utilizzarli immediatamente puoi usare BIRT -beautiful e gratis

Answer 5

Offrire più uscite come JSON, CSV, YAML o XML è buono - questo dà all'utente finale confort, ad un livello molto piccolo costo! Il dumping dei dati è sempre più semplice rispetto all'elaborazione e si dice che analizzano già JSON per qualche ragione: è molto più semplice collegarlo alla propria API piuttosto che implementare, ad esempio, un parser XML. Oggigiorno vedo parser XML dappertutto, quindi probabilmente non dovrebbe essere un problema, ma mi piace la natura più "air-ish" di JSON; Ho guardato un po 'in YAML ma non l'ho mai usato, ma sembra promettente, lo userò definitivamente per i file di configurazione del mio prossimo progetto.

Dal punto di vista della sicurezza di tutto ciò che elabora dinamicamente qualsiasi input fornito da un utente, si dovrebbe trattare tale input come qualcosa che non si attiverà nemmeno con un stick.

IMHO stateless REST è meglio di SOAP perché è meno overhead, si può facilmente comunicare con un REST-api a mano usando curl o wget dal terminale. Salta in avanti, per così dire.

Ti consiglio di fare un respiro profondo, una matita & una carta, sedersi e abbozzare tutto ciò che sarà necessario. Quindi rimuovi le cose meno importanti, prendi un nuovo foglio e inizia a organizzarlo. Puoi aggiungere le cose meno importanti nella prossima versione dell'API.

Prova a progettare l'API in modo che non ti blocchi in un angolo, non fare ipotesi su dove sta andando a testa successiva.