Utilizzo dei verbi HTTP LINK e UNLINK in un'API REST

Question

Attualmente sto lavorando all'implementazione di un'API REST. Ho un modello di risorse con un gran numero di relazioni tra le singole risorse.

La mia domanda è: come si collegano reciprocamente due risorse esistenti (stabilendo una relazione) in modo RESTful?

Una soluzione che ho trovato era l'uso dei verbi HTTP LINK e UNLINK. L'utente dell'API potrebbe collegare due risorse utilizzando LINK e l'URI seguente:/resource1 /: id1/resource2 /: id2.

Il problema con questa soluzione è la mancanza di supporto per i verbi LINK e UNLINK. Né http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html o http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol menzionano i verbi, e sembrano essere in gran parte "dimenticati". Tuttavia, l'originale RFC 2068 dichiara che esistono.

Mi piace molto questa soluzione. Tuttavia, temo che molti utenti/clienti dell'API non saranno in grado di gestire la soluzione a causa della mancanza di supporto per LINK/UNLINK. È una soluzione accettabile o esistono soluzioni migliori e/o più eleganti per il collegamento di risorse esistenti in un'API RESTful?

Grazie

Answer 1

io uso LINK e UNLINK nel mio (su misura, azienda-interno) web app. Io uso http://tools.ietf.org/html/draft-snell-link-method come riferimento per l'implementazione.

ho scoperto che ci sono tre tipi di clienti:

1. Coloro che supportano solo GET e POST, prendendo spunto da elemento di HTML <form>.
2. Quelle che supportano solo GET, PUT, POST e DELETE. Questi prendono spunto dalle API tipo CRUD e RPC-fingendo-di-essere-REST.
3. Quelli che consentono qualsiasi metodo. La pubblicazione di PATCH come RFC ufficiale ne ha aumentato la quantità, così come la crescita di WebDAV, anche se a volte i client di categoria 2 supportano anche PATCH.

Essendo attualmente sviluppiamo i nostri clienti in-house che non hanno questo problema, ma ho guardato dentro e ha fatto considerare i pro ei contro prima di definire il mio API, nel caso in cui abbiamo voluto consentire di terza clienti di partito. La mia soluzione (dal momento che dovevamo supportare i client HTML senza Javascript in ogni caso) era consentire a POST di sovrascrivere il metodo fornendo un campo _METHOD (application/x-www-form-urlencoded) e quindi avere la mia funzione post() sul palmare back-end nella funzione appropriata per l'intenzione Metodo HTTP In questo modo, qualsiasi client nel futuro, ad esempio, nella classe 2, può utilizzare PUT e DELETE ma inserire PATCH, LINK e UNLINK in una richiesta POST. Ottenete il meglio da entrambi i mondi: metodi ricchi da parte dei clienti che lo supportano, e tuttavia supportano ancora i client di bassa qualità attraverso il tunneling POST.