ebay come interfaccia API per un portale web

Question

Abbiamo sviluppato un portale Web B2B per lavori di grafica simile a Camera Ready Art (www.camerareadyart.com). È rivolto a persone che desiderano convertire bitmap in grafica vettoriale, progettazione di logo ed elaborazione generale di immagini come colorare le immagini in bianco e nero a colori, ecc.

Vogliamo aggiungere funzionalità in modo che le persone (i nostri clienti) possano utilizzare una serie di API che forniamo per pubblicare il loro lavoro direttamente dal loro sito senza dover visitare il nostro sito letteralmente per pubblicare il loro lavoro.

Non ho mai fatto nulla di simile fino ad oggi, quindi non ho idee su come posso implementare qualcosa del genere. Voglio anche sapere come possiamo implementare la sicurezza in modo che solo coloro che sono autorizzati possano pubblicare il loro lavoro?

Qualcuno può darmi idee su come possiamo fare qualcosa del genere.

Answer 1

Questa domanda copre un'area molto ampia e dubito che ogni singola risposta possa coprire le questioni in dettaglio. Quello che posso fare è offrire alcuni punti di partenza basati sugli errori che ho commesso.

Costruisci sulla tua API
Non aggiungere funzionalità API a un sistema esistente. In questo modo:

• comporta un ulteriore carico di prova (dovrai testare sia la tua app che l'API in modo indipendente)
• determina un aumento dei costi complessivi di manutenzione
• si traduce in un'API di qualità inferiore rispetto a ciò che si desidera offrire

Il tuo obiettivo generale dovrebbe essere quello di creare prima l'API, quindi la tua app sulla tua API. Ciò ha i seguenti vantaggi:

• il test dell'API viene eseguito intrinsecamente durante il test dell'app
• non dimenticherai di aggiungere alcun metodo API richiesto

La tua app e la tua logica applicativa (l'API) saranno logicamente separate - ci sarà una chiara separazione tra loro in termini di cosa fa ogni lato dell'equazione e di cosa è responsabile. Ciò contribuirà a guidare lo sviluppo. Ciò consentirà inoltre di posizionare l'app e l'API su macchine diverse con estrema facilità, quando e quando necessario.

L'uso della propria API è un punto molto importante. Il design della tua API inizialmente non sarà ottimale e solo usandolo tu stesso sarai in grado di offrire alle persone le funzionalità effettivamente necessarie in modo efficiente.

Finirai con un sistema che assomiglia approssimativamente a questo:

-------------                          -------------
|           |                          |           |
| Your APP  | <= HTTP communication => | Your API  |
|           |                          |           |
-------------                          -------------

Ciò evidenzia alcuni ulteriori vantaggi: puoi sostituire "La tua APP" con qualsiasi altra app, consentendo ai tuoi clienti di creare app per gestire le cose nel modo che funziona meglio con loro. Puoi anche creare nuove versioni della tua app sull'API esistente: passare a una nuova versione del tuo sito web pubblico può essere molto più semplice.

Progettazione dei tuoi URL: mappatura su classi e metodi
La scelta di URL sensibili è tanto un problema quanto la scelta di nomi di classi e metodi sensibili. Derivare gli URL dalle classi e dai loro metodi è un buon approccio. Se non esiste una correlazione ragionevole tra URL e classi / metodi, troverete cose più difficili da mantenere a lungo termine.

Preferisco personalmente associare gli URL a classi e metodi nei seguenti modi:

• associa le classi alle directory di livello superiore
• associa i metodi alle sottodirectory delle directory di livello superiore

Esempio:
L'URL della tua API è https://api.camerareadyart.com .
Hai un oggetto image con i metodi toColour () e toBlackAndWhite () .

Questo può essere associato a:

https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/

Allo stesso modo per la conversione da bitmap a vettoriale:

https://api.camerareadyart.com/bitmap/toVector/

Progettazione di risposte
Quando qualcuno riceve dati da o dati POST a uno dei tuoi URL, cosa succede? Come vengono gestiti gli errori, come vengono gestite le eccezioni? In che forma prendono le risposte?

Non posso dirti cosa fare qui. Personalmente preferisco mappare le cose il più vicino possibile a HTTP e poi andare oltre questo solo quando necessario.

Ad esempio, se una richiesta in arrivo viene accettata e viene elaborata ma si verifica un errore interno, emetterei una risposta di stato 500. Allo stesso modo se un determinato metodo API richiede un'autenticazione che non è stata fornita, potrei emettere un 403. Sfruttare le funzionalità HTTP esistenti ti impedisce di dover reinventare determinate cose.

Usa gli aspetti esistenti di HTTP
Oltre a utilizzare i codici di stato HTTP in modo ragionevole, assicurati di cercare un metodo solo HTTP per fare qualcosa prima di lanciare la tua soluzione.

Desideri che l'utente specifichi se il formato di risposta deve essere XML o JSON? Usa l'intestazione HTTP Accept.

Vuoi reindirizzare un client a un URL diverso per afferrare il risultato di una richiesta? Utilizza l'intestazione della posizione HTTP.

Answer 2

Ovviamente devi avere i tuoi servizi web back-end progettati e funzionanti. Tuttavia, tutte le funzionalità aggiuntive (sicurezza, limitazione, gestione delle chiavi OAuth, portale degli abbonati, console interattiva per provare le API, ecc.) Sono un set abbastanza standard di funzionalità che probabilmente non dovresti sviluppare da solo.

Esistono soluzioni commerciali di gestione delle API sul mercato. Lavoro per WSO2, che ha un gestore API WSO2 open source (licenza Apache) al 100%, che puoi scaricare gratuitamente qui o utilizza come versione ospitata su cloud in WSO2 API Cloud .