Autorizzazione API RESTful per campi aggiornabili

Naviga le tue risposte
0

Ho una risorsa come segue dove state è un enum: 

{
  id: 123,
  industry: {
    id: 245,
    name: "Farming"
  },
  "scheduleDate": "2018-01-01",
  "state": "Requested|Approved|Standardized|Canceled|Done"
}

Le uniche proprietà che possono cambiare sono scheduledDate e state e non sono sicuro di quale sia il modo corretto di farlo nella mia situazione.

Sarebbe opportuno utilizzare il metodo PATCH per consentire l'aggiornamento solo di quei campi e lo farei, tuttavia voglio che determinati gruppi siano autorizzati a fare queste azioni, potrebbe essere che quella persona sia autorizzata solo a cambiare le statistiche in Standardized e non sono sicuro che PATCH funzioni nel mio caso.

Quali potrebbero essere i modi alternativi per farlo? Ho pensato di andare in questo modo:

  • /api/v1/resource/123/reschedule
  • /api/v1/resource/123/approve
  • /api/v1/resource/123/standardize
  • /api/v1/resource/123/cancel

Questo non sembra male ma non è 100% REST.

Sto utilizzando ASP.NET Core insieme a Identity Server per implementarlo.

Quindi la vera domanda è. Se dovessi usare PUT , sarebbe possibile limitare determinati utenti dall'aggiornamento di questo campo? Non sono riuscito a trovare se fosse possibile.

    
posta Evaldas Buinauskas 05.08.2018 - 15:09
fonte

2 risposte

1

Non vedo un vero problema con POST / PUT / PATCH: questo è troppo teorico senza vedere il caso nel contesto. L'API dovrebbe servire bene i casi d'uso - questo è il punto di partenza, che guida la scelta di risorse, URL, indirizzi. In altre parole, l'API è per gli sviluppatori.

Personalmente mi piace POST qui. Da "REST API Design Cookbook" di Mark Masse: "Regola: POST deve essere utilizzato per eseguire i controller" con un esempio: 

POST /alerts/245743/resend

"This is the second use of POST in the design of REST APIs."

Cioè, i verbi HTTP vanno bene per operazioni puramente CRUD, ma la tua API non deve essere limitata a questo. È meglio usare le operazioni dal dominio. E credo che questo sia il tuo esempio nella domanda.

E, sì, se vuoi tutto il percorso per link - allora è anche utile fornire un client alle operazioni disponibili può seguire

    
risposta data 05.08.2018 - 20:09
fonte
1

Gli argomenti su se qualcosa è al 100% o meno possono impedirti di ottenere qualcosa e di migliorare nel tempo. Entrambi gli approcci funzioneranno. Puoi fare le cose in un modo più RPC (con i tuoi endpoint separati per il tipo di azione), e quella sarebbe una cosa verosimilmente corretta da fare. Puoi aggiornare la tua voce con PUT o PATCH e sarebbe anche una cosa verosimilmente corretta.

Il trade-off non è poi così grave:

  • RPC: facile da comprendere e facile da implementare
  • REST with PATCH: un po 'più difficile da capire, ma non molto
  • REST con PUT: qui è possibile richiedere la sostituzione completa, in particolare perché sono solo 2 i campi che vengono aggiornati.

Fai quello che senti sarà il migliore Nessuna delle tue alternative è negativa.

    
risposta data 05.08.2018 - 15:33
fonte

Leggi altre domande sui tag

Architecture for mobile card game Specifica del tipo concreto di ActionResult