Confusione tra nome e verbo negli URL di riposo

Ho studiato su Internet delle API riposanti che si concentra su nomi e non verbi nel modello di URL, ma ora vedo più collegamenti che utilizzano i verbi nell'URL.Confusione tra nome e verbo negli URL di riposo

Ecco un esempio.

POST/v1/pagamenti/autorizzazione/< ID-autorizzazione >/capture

POST/v1/pagamenti/autorizzazione/< ID-autorizzazione >/vuoto

POST/v1/pagamenti/autorizzazione/< ID-autorizzazione >/ri-autorizzare

questo è Paypal apis. PayPal API

anche su wikipedia sulla pagina HTATEOAS hanno fornito un esempio;

<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

link: Wiki HATEOAS

Qualcuno può aiutarmi ad ottenere un po 'di chiarezza su questo? perché 'capture', 'void', 'deposit', 'withdraw', 'close' sono nell'URI perché sono tutti verbi e non sostantivi?

o va bene usare questo tipo di parole in rest-full apis url?

fonte

2014-11-25 Uzair Xlade

In REST, il verbo è il metodo HTTP. Nel tuo esempio è POST ma potrebbe anche essere GET, PUT o DELETE.

Il nome è la risorsa identificata dall'URL. Nel tuo esempio i "nomi" sono /v1/payments/authorization/<Authorization-Id>/capture, ecc.

Come puoi vedere, questo non è proprio un sostantivo dato che capture è un verbo: acquisire un'autorizzazione di pagamento. Questo non è RESTful poiché è un comando, un verbo, non una cosa, un nome.

Un modo migliore sarebbe quello di modellare questi comandi come cose come /v1/payments/authorization/<Authorization-Id>/capturecommand. Questo comando sarebbe una cosa, un nome. Potrebbe avere lo stato, ad esempio se ha avuto successo, qual è stato il risultato, ecc.

C'è un sacco di codice là fuori che afferma di essere RESTful e non lo è.

fonte

2014-11-25 08:39:28

Mi piace soprattutto la dichiarazione finale: '> C'è un sacco di codice là fuori che sostiene di essere riposante e isn't.' –

Alcuni frammenti dalla REST API Design Rulebook sui diversi tipi di risorse:

documento

Una risorsa documento è un concetto singolare, che è simile a un'istanza di un oggetto o un database registrare.

Esempio: http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet

Collection

Una risorsa collezione è una directory di server gestiti di risorse. I clienti possono proporre nuove risorse da aggiungere a una raccolta. Tuttavia, spetta alla raccolta scegliere per creare una nuova risorsa oppure no.

Esempio: http://api.soccer.restapi.org/leagues/seattle/teams

Conservare

Un negozio è un repository di risorse client gestiti. Una risorsa del negozio consente a un client API di inserire risorse , recuperarle e decidere quando eliminarle. Da soli, i negozi non creano nuove risorse; quindi un negozio non genera mai nuovi URI. Invece, ciascuna risorsa memorizzata ha un URI che è stato scelto da un client quando è stato inizialmente inserito nello store .

Esempio: PUT /users/1234/favorites/alonso

controller modelli di risorse

un controller un concetto procedurale. Le risorse del controller sono come funzioni eseguibili, con parametri e valori di ritorno; ingressi e uscite.

Come l'uso di un'applicazione web tradizionale di moduli HTML, un API REST si basa sul controller risorse per eseguire azioni specifiche dell'applicazione che non può essere logicamente mappati a uno dei metodi standard (creare, recuperare, aggiornare ed eliminare, noto anche come CRUD).

I nomi dei controller in genere vengono visualizzati come l'ultimo segmento in un percorso URI, senza risorse figlio per seguirli nella gerarchia.

Esempio: POST /alerts/245743/resend

Sulla base delle definizioni del libro, gli URI che hai postato, probabilmente rientrano nella controller tipo delle risorse, di cui il libro si afferma in seguito:

Regola: deve essere utilizzato un verbo o una frase verbale per i nomi dei controller

Esempi:

http://api.college.restapi.org/students/morgan/register

http://api.example.restapi.org/lists/4324/dedupe

http://api.ognom.restapi.org/dbs/reindex

http://api.build.restapi.org/qa/nightly/runTestSuite

Altre regole di denominazione, solo per completezza

Regola: Un sostantivo singolare dovrebbe essere utilizzato per i nomi dei documenti

regola: un sostantivo plurale dovrebbe essere utilizzato per i nomi di raccolta

regola: un sostantivo plurale dovrebbe essere utilizzato per i nomi dei negozi

fonte

2014-11-25 08:51:54

Gli autori di questo libro può avere l'opinione, che RPC va bene. Potrebbero persino chiamare la "risorsa controller" RPC. Ma non sono d'accordo sul fatto che questo è un buon consiglio poiché non vi è alcuna risorsa su un URI di questo tipo che possa essere utilizzato con gli altri verbi HTTP. 'GET /.../ reindex' non ha senso che è un forte indicatore che l'intero URL non ha senso. –

@LutzHorn Il libro non implicava che 'GET /../ reindex' dovrebbe essere usato. Non voglio citare il tutto, ma l'implicazione era usare POST. GET dovrebbe essere usato per un'operazione di recupero CRUD, che il libro afferma chiaramente non dovrebbe essere definito da un controller –

Quindi un tale controller non è una risorsa nel senso REST. Io voto contro questo concetto. –

Il trucco è quello di rendere tutti i nomi (o enti) che operano con i verbi CRUD.

Quindi anziché;

POST /v1/payments/authorization/<Authorization-Id>/capture 
POST /v1/payments/authorization/<Authorization-Id>/void 
POST /v1/payments/authorization/<Authorization-Id>/reauthorize

Fare questo;

capture -> POST /v1/payments/authorization/<Authorization-Id> 
void -> DELETE /v1/payments/authorization/<Authorization-Id> 
reauthorize -> delete first then create again.

fonte

2016-08-15 13:32:16 user3528340

Confusione tra nome e verbo negli URL di riposo

risposta

Problemi correlati