Devo fornire librerie client in alcune lingue selezionate insieme alle API stesse?

2

Dire che ho creato un servizio web basato su API RESTful. Ha senso anche fornire agli utenti una libreria client per l'API in alcune lingue selezionate che sono probabilmente le più utilizzate? Con la libreria client, intendo un involucro sottile attorno a tutte le chiamate API, in modo che gli utenti possano chiamare metodi nella loro lingua e ottenere oggetti nella loro lingua, che possono manipolare facilmente.

Se non fornisco un client, gli utenti creeranno le loro versioni dei client e dovranno preoccuparsi di creare le proprie versioni degli oggetti del modello di dati e dovranno anche prendere decisioni come la libreria HTTP da utilizzare .

Se fornisco un client, c'è innanzitutto la domanda su quali lingue suppongo. Inoltre, potrebbe diventare difficile mantenere la coerenza tra l'API e le librerie client. Inoltre, c'è l'argomento che l'API è ridondante se fornisco una libreria client. Posso semplicemente fornire la libreria del client da solo. Quindi ho bisogno di mantenere il contratto API in un solo posto anziché in due.

Sono un po 'sotto pressione per fornire la libreria client perché molti utenti sono preoccupati dell'utilizzo dell'API (molto probabilmente perché dovranno scrivere autonomamente questa libreria se devono usare l'API). Qual è il modo migliore per andare? Ci sono altri pro e contro che mi mancano? Apprezzo qualsiasi consiglio / aneddoto.

    
posta Hari Menon 10.06.2013 - 13:45
fonte

2 risposte

4

Molte organizzazioni che offrono API RESTful offrono anche alcuni codici client, ma forniscono anche l'API completa separatamente. Penso che ci siano solo poche combinazioni sensate:

  1. API e client
  2. Solo API
  3. Client-only

Ho ordinato quelli in termini di preferenza, con API e client che sono i più favoriti. Questo perché, a meno che la documentazione dell'API non sia perfetta , probabilmente non sarà completamente chiaro in che modo mettere insieme determinate operazioni per fare qualcosa di utile. È qui che il codice cliente è utile.

In generale, supporta le lingue più comuni come client. Personalmente, vorrei creare delle librerie (non in un ordine particolare):

  • PHP
  • Rubino
  • Python
  • .NET
  • Java
  • Node.JS

Qualsiasi altra cosa è probabilmente superflua, o potrebbe essere costruita controllando il codice dei tuoi clienti esistenti. Probabilmente è consigliabile aprire i client, anche se non il resto del codice, in modo che la comunità possa fornire correzioni di bug e funzionalità extra. Non ci hai detto molto sul tuo scenario esatto, quindi è difficile dire con certezza se sarebbe appropriato in questo caso.

    
risposta data 10.06.2013 - 14:56
fonte
0

Dipende da quanti utenti ci saranno per ogni lingua e da quanto tempo ci vorrà per scriverli. Se hai solo una manciata di utenti, c'è poco IMO. Se hai (o prevedi di avere) migliaia di utenti (ed è finanziariamente fattibile dal punto di vista del business), probabilmente vale la pena farlo.

La libreria client sarà un semplice wrapper API o fornirai più funzionalità nel tempo? Inoltre, potresti avere più versioni di ciascuna libreria client da conservare.

Potrebbe essere necessario diventare un 'esperto' per fornire una libreria conforme agli idiomi molto diversi per ogni lingua.

Non dimenticare il lato della manutenzione delle cose. Le modifiche alle API potrebbero richiedere modifiche per ogni libreria supportata.

    
risposta data 15.01.2019 - 11:57
fonte

Leggi altre domande sui tag