Design Web Api - Uso di nomi e verbi

Question

Design Web Api - Uso di nomi e verbi

#1 da (2 voti)

1

Ho questa situazione progettuale al lavoro. Abbiamo un'applicazione Web-Api interna e un'applicazione di moduli Web di Asp.Net (UI). L'applicazione Web chiama Web-Api per aggiornare un contraente.

public Class Contractor {
    public string Id {get;set;}
    public string Name {get;set;}
    <<Ton of other Properties>>
    public string Status {get;set;}
}

In genere l'app UI può aggiornare l'appaltatore completo inviando tutti i dettagli, ad eccezione dello stato. Un utente può modificare lo stato in chiuso facendo clic su un pulsante speciale "Chiudi" sullo schermo. In questo caso l'architetto del team di interfaccia utente non desidera inviare l'appaltatore completo con lo stato come chiuso. Inoltre, prima che un contraente venga chiuso, esiste una serie di regole aziendali che devono essere soddisfatte. Quindi questo non è un aggiornamento diretto.

Quindi possiamo fornire un percorso come "/ api / Contractor / {id} / Chiudi"? Non è questo contro il principio RESTFul di non usare i verbi nei nomi e di occuparsi delle risorse invece delle azioni. Posso fare un'eccezione in questo caso?

api-design rest web-api

posta Sri Harsha Velicheti 02.02.2015 - 03:52

fonte

1 risposta

Leggi altre domande sui tag api-design rest web-api

è un modello esattamente uguale a una entità aziendale? RESTful Backend - Quanto accoppiato dovrebbe essere il mio back end e front end?

score 2 · Answer 1

Isn't this against the RESTFul principle of not using Verbs in the nouns and dealing with Resources instead of actions.

No - REST non si cura di come si scrive l'identificatore.

È in violazione delle linee guida sulla progettazione di URI, esattamente per la ragione specificata - stai nominando un'entità (un nome) con un verbo. HTTP ti sta già dando dei verbi, quindi non ne hai bisogno nell'identificatore.

La soluzione più comune a questo tipo di problema è creare una risorsa che rappresenti il nome specifico da manipolare, ad esempio

/api/Contractor/{id}/status

Also before a Contractor is closed there a a set of Business rules that need to be satisfied.

Questo suggerisce che la risorsa che viene manipolata non è uno stato, ma un evento o un comando, ad esempio: ContractorDismissed, e la modifica allo stato è un effetto collaterale.