rest - differenza tra post e put




Come creare URL REST senza verbi? (6)

Forse qualcosa come:

PUT /parameters/activation HTTP/1.1
Content-Type: application/json; encoding=UTF-8
Content-Length: 18

{ "active": true }

Sto lottando per determinare come progettare URL restful. Sono tutto per l'approccio rilassante dell'uso di URL con nomi e non i verbi non capisco come farlo.

Stiamo creando un servizio per implementare un calcolatore finanziario. La calcolatrice accetta una serie di parametri che verranno caricati tramite un file CSV. I casi d'uso implicherebbero:

  1. Carica nuovi parametri
  2. Ottieni gli ultimi parametri
  3. Ottieni parametri per una determinata data di lavoro
  4. Rendi attivo un set di parametri
  5. Valida un set di parametri

Trovo che l'approccio restful sarebbe avere i seguenti URL tipo:

/parameters
/parameters/12-23-2009

È possibile ottenere i primi tre casi d'uso con:

  1. POST in cui includi il file dei parametri nella richiesta di post
  2. Ottieni il primo URL
  3. Ottieni il secondo URL

Ma come si fa il 4 ° e il 5 ° caso d'uso senza un verbo? Non avresti bisogno di URL come:

/parameters/ID/activate
/parameters/ID/validate

??


I requisiti di attivazione e convalida sono situazioni in cui si sta tentando di modificare lo stato di una risorsa. Non è diverso che fare un ordine "completato", o qualche altra richiesta "presentata". Esistono numerosi modi per modellare questo tipo di cambiamento di stato, ma trovo che spesso funzioni sia creare risorse di raccolta per risorse dello stesso stato e quindi spostare la risorsa tra le raccolte per influenzare lo stato.

Ad esempio, crea alcune risorse come,

/ActiveParameters
/ValidatedParameters

Se si desidera rendere attivo un insieme di parametri, aggiungere tale set alla raccolta ActiveParameters. Potresti passare il set di parametri come corpo di entità o potresti passare un url come parametro di query, come segue:

POST /ActiveParameters?parameter=/Parameters/{Id}

La stessa cosa può essere eseguita con / ValidatedParameters. Se i parametri non sono validi, il server può restituire "Richiesta non valida" alla richiesta per aggiungere i parametri alla raccolta di parametri convalidati.


In un ambiente REST, ogni URL è una risorsa univoca. Quali sono le tue risorse? Un calcolatore finanziario non ha risorse ovvie. Hai bisogno di scavare in ciò che stai chiamando parametri e tirare fuori le risorse. Ad esempio, un calendario di ammortamento per un prestito potrebbe essere una risorsa. L'URL per il calendario potrebbe includere data_inizio, termine (in mesi o anni), periodo (quando l'interesse è composto), tasso di interesse e principio iniziale. Con tutti questi valori hai un calendario di pagamenti specifico:

http://example.com/amort_cal/2009-10-20/30yrsfixed/monthly/5.00/200000

Ora, non so cosa stai calcolando ma il tuo concetto di un elenco di parametri non suona RESTful. Come ha detto qualcun altro, le tue esigenze sopra riportate sono più XMLRPC. Se stai provando per REST hai bisogno di nomi. I calcoli non sono nomi, sono verbi che agiscono su nomi. Hai bisogno di girarlo per tirare fuori i nomi dai tuoi calc.


Ogni volta che sembra che tu abbia bisogno di un nuovo verbo, pensa invece di trasformare quel verbo in un nome. Ad esempio, attiva "attiva" in "attivazione" e "convalida" in "convalida".

Ma proprio da quello che hai scritto direi che la tua applicazione ha problemi molto più grandi.

Ogni volta che viene proposta una risorsa chiamata "parametro", dovrebbe inviare delle bandiere rosse nella mente di ogni membro del team di progetto. 'parametro' può letteralmente essere applicato a qualsiasi risorsa; non è abbastanza specifico.

Cosa rappresenta esattamente un "parametro"? Probabilmente un numero di cose diverse, ognuna delle quali dovrebbe avere una risorsa separata dedicata ad essa.

Un altro modo per ottenere questo - quando si discute della propria applicazione con gli utenti finali (quelli che presumibilmente sanno poco della programmazione) quali sono le parole che usano ripetutamente?

Queste sono le parole che dovresti progettare per la tua applicazione.

Se non hai ancora avuto questa conversione con i potenziali utenti, interrompi tutto subito e non scrivere un'altra riga di codice finché non lo fai! Solo allora il tuo team avrà un'idea di ciò che deve essere costruito.

Non so nulla di software finanziario, ma se dovessi indovinare, direi che alcune risorse potrebbero andare sotto nomi come "Report", "Payment", "Transfer" e "Currency".

Ci sono una serie di buoni libri su questa parte del processo di progettazione del software. Due che posso raccomandare sono modelli di progettazione e analisi basati sul dominio .


Suggerirei le seguenti risorse e metodi Meta.

Rendi i parametri attivi e / o convalidali:

> PUT /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Content-Type: application/json
> Connection: close
>
> {'active': true, 'require-valid': true}
>
< HTTP/1.1 200 OK
< Connection: close
<

Controlla se i parametri sono attivi e validi:

> GET /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Connection: close
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Connection: close
<
< {
<     'active': true,
<     'require-valid': true,
<     'valid': {'status': false, 'reason': '...'}
< }
<

Modifica: in effetti l'URI avrebbe impedito alle richieste GET di rimanere idempotenti.

Tuttavia, per la convalida, l'uso di codici di stato HTTP per notificare la validità di una richiesta (per crearne uno nuovo o modificare un "parametro" esistente) si adatterebbe con un modello Restful.

Segnalare con un codice di stato 400 Bad Request non valida se i dati inviati sono / non sono validi e la richiesta deve essere modificata prima di essere inviata di nuovo ( Codici di stato HTTP / 1.1 ).

Questo si basa sulla convalida al momento dell'invio, piuttosto che differirlo come nel tuo caso d'uso. Le altre risposte hanno soluzioni adatte a quello scenario.





restful-url