Gli URL di incorporamento come parametri di query negli URL sono un modello di progettazione API REST accettabile? [chiuso]

Question

Gli URL di incorporamento come parametri di query negli URL sono un modello di progettazione API REST accettabile? [chiuso]

#1 da (3 voti)
#2 da (3 voti)

4

Stiamo progettando alcuni servizi web orientati alle risorse.

Il servizio B deve essere in grado di effettuare chiamate al servizio A passando in un riferimento a una risorsa nel servizio B che il servizio A utilizzerà quando formulerà la sua risposta. Forse il servizio A ha già delle conoscenze sulla risorsa del servizio B da un'interazione precedente.

per es.

GET http://serviceA.com/resource/123?widget=http://serviceB.com/widget/456

(ovviamente il parametro di query 'widget' dovrebbe essere codificato in modo appropriato)

In pratica vedo pochissimi esempi di questo genere di cose. A volte lo vedi sul web, ad es. un esempio potrebbe essere URI di reindirizzamento in Google OAuth ( link )

Sembra che sia più comune costruire una certa conoscenza delle risorse del servizio B nel servizio A in modo da poter effettuare una chiamata come:

GET http://serviceA.com/resource/123?widget=456

Questo sembra spezzare i principi di progettazione orientata alle risorse.

Gli URL di incorporamento come parametri di query sono un approccio di progettazione appropriato o ci sono problemi con esso?

Chiaramente potrebbe portare a problemi con la lunghezza dell'URL con qualsiasi agente utente che abbia limitazioni sulla lunghezza dell'URL. E sembra un po 'brutto. Ma oltre a ci sono altri aspetti negativi? Perché non viene usato di più? O forse lo è? È perché la maggior parte dei progetti di API basati su REST non sono veramente RESTful (orientati alle risorse), il che non vuol dire che siano entrambi negativi ( link )

design api rest

posta Martin Bayly 22.04.2015 - 22:16

fonte

2 risposte

Leggi altre domande sui tag design api rest

In che modo i tipi di unione sono migliori per la correttezza di un'interfaccia comune? Come si può aggiungere "yield" come parola chiave in ES6 se non era una parola riservata?

score 3 · Answer 1

Questo, a mio avviso, dipende dal modo in cui usi i parametri URL. Il passaggio degli URL come dati effettivi da manipolare va bene.

Immagina un servizio REST per gestire i segnalibri Web. Supponiamo che associ alcuni metadati con i segnalibri (ad esempio data aggiunta, icona, ecc.). Tramite il canone REST una richiesta che richiede tali dati per un particolare segnalibro sarà una richiesta GET e dovrà passare l'URL del segnalibro come parametro.

D'altra parte, probabilmente non è una buona idea usare i parametri che trasportano URL per controllare gli aspetti altri . Per esempio. Non posso aspettarmi di vedere qualcosa come &redirect=http://... tra i parametri di un'API REST ben progettata. (Si noti che OAuth è non un'API REST affatto).

score 3 · Answer 2

Questo mi sembra un caso diretto del operatore di introduzione di Granovetter come applicata dal cliente in una richiesta - la risorsa che riceve la richiesta non ha bisogno di conoscenza preliminare della specifica risorsa esterna referenziata (solo che ha un comportamento compatibile), e fintanto che la risorsa esterna a cui si fa riferimento viene trattata come oggetto o oggetto della richiesta di non essere partito dallo stile RESTful.

QuiAliceèilcliente,BobèlarisorsachericevelarichiestaeCarolèlarisorsaesternaacuifariferimentonellarichiesta.BobnonhaalcunaconoscenzaspecificaprecedentediCarolcomeevidenziatodallamancanzadiunbordochelicollega.fooèsemplicementela variabile metasintatica predefinita per un messaggio arbitrario.