È rilassante avere i verbi sul percorso HTTP invece del metodo HTTP?

Is it restful to have verbs on the HTTP path instead of the HTTP method?

Sì. REST non si cura di quale ortografia si usa per i propri identificatori.

I've only been told again and again that this is not restful because it must only use GET, POST, PUT, DELETE and PATCH to remain restful.

Uno dei vincoli dell'architettura REST è l'interfaccia uniforme ; descrivendolo nella sua tesi, Fielding ha scritto

By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability....

Non c'è nulla di particolarmente magico in [GET, POST, PUT, DELETE, PATCH]. Molto tempo fa, quella lista sarebbe probabilmente [GET, HEAD, POST], perché quelli erano gli unici metodi che erano stati standardizzati in RFC 1945 . Gli altri sono stati documentati con questo avviso :

This appendix documents protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.0 applications. Implementors should be aware of these features, but cannot rely upon their presence in, or interoperability with, other HTTP/1.0 applications.

L'interoperabilità è fondamentale, nel senso che i client, i server e i componenti intermedi che condividono la comprensione della semantica del messaggio possono tutti collaborare per produrre un risultato - senza che deve comprendere il carico utile del messaggio.

Oggi abbiamo un registro dei metodi , con molti metodi diversi che potresti voglio usare, incluso (come accade) LOCK e UNLOCK. Quindi, assumendo che la tua semantica sia d'accordo con quelle documentate nel registro, potresti usarle.

Nei casi in cui controlli sia il client che il server, limitarti ai metodi registrati è meno critico di quanto non sarebbe altrimenti.

Se stai mirando a clienti che capiscono il codice su richiesta, puoi dare a un client generico un link per scaricare il codice cliente per interagire con i tuoi servizi.

Ci sono molti problemi con l'utilizzo di metodi HTTP personalizzati, il che significa che raramente è una buona idea. Alcuni di questi sono:

• Alcuni server proxy e firewall non inoltrano richieste che li utilizzano
• Spesso l'implementazione richiede una configurazione server personalizzata che potrebbe non essere possibile su host condivisi (impedendo così l'uso di tali servizi)
• La semantica del metodo potrebbe non essere chiara (è una chiamata al tuo metodo personalizzato idempotente? Sappiamo che una chiamata a un metodo PUT dovrebbe essere, e che probabilmente un metodo POST non lo è, il che è un chiaro vantaggio dell'uso questi due tipi di metodo)
• Una caratteristica fondamentale dei servizi RESTful è la possibilità di scoprire le operazioni che possono essere eseguite automaticamente su una risorsa (ad esempio HATEOAS ). Ma le tecniche standard (ad esempio il uso di elementi di collegamento nei documenti xml o JSON-LD ) per fare ciò fornisce solo i mezzi per specificare l'URI da utilizzare per tale operazione, non quale metodo di richiesta dovrebbe essere usato. Ciò pertanto influisce sulla rilevabilità della tua API.

In generale, l'utilizzo di una struttura /noun-type/specific-noun-identifier/verb è più semplice e comprensibile rispetto ai metodi HTTP personalizzati, quindi perché passare allo sforzo quando ha potenziali conseguenze negative?

Se si desidera utilizzare un "verbo" personalizzato, esiste già un meccanismo per questo: verbo tunneling tramite il metodo x-http -override header . Questo ti dà i benefici ed evita la maggior parte delle insidie che Jules ha elencato.

It is possible to instruct network intermediaries (proxies, firewalls, and so on) inspecting traffic at the application protocol layer (for example, HTTP) to block requests that contain certain HTTP verbs. In practice, GET and POST verbs are rarely blocked (traditional web pages rely heavily on these HTTP methods), while, for a variety of reasons (such as security vulnerabilities in prior protocols), other HTTP methods (PUT, DELETE, and so on) are at times blocked by intermediaries. Additionally, some existing HTTP libraries do not allow creation of requests using verbs other than GET or POST. Therefore, an alternative way of specifying request types which use verbs other than GET and POST is needed to ensure that this document works well in a wide range of environments.

To address this need, the X-HTTP-Method header can be added to a POST request that signals that the server MUST process the request not as a POST, but as if the HTTP verb specified as the value of the header was used as the method on the HTTP request's request line, as specified in [RFC2616] section 5.1. This technique is often referred to as "verb tunneling".