While this makes sense for the particular scenario, it's less like the posting of a new resource and more like invoking a method on an object.
RFC 7231 4.3.3
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
In breve, nell'interfaccia uniforme delle risorse HTTP, il POST è il catch-all; usi POST se nessuno degli altri metodi è più adatto
(Tieni sempre presente che il Web ha avuto un successo spettacolare anche se il tipo di supporto HTML offre solo GET e POST).
Does this way of doing things (resources with "methods" as well as data, sort of like OOP in API form) count as RESTful?
In che modo il client sa di inviare quel corpo del messaggio a quell'endpoint usando quel metodo? Una delle idee chiave in REST è che la comunicazione di tale conoscenza avviene in banda ; il client sa di inviare quel messaggio a quell'endpoint perché la rappresentazione dello stato dell'applicazione che è stata appena fornita dal server lo ha detto a.
In una parola: hypermedia .
In altre parole, pensa a come lo faresti sul Web: caricheresti qualche segnalibro, che ti restituirebbe una rappresentazione con un gruppo di collegamenti semanticamente annotati. Dovresti seguire il link del server di shutdown, che potrebbe restituirti una rappresentazione con un modulo in modo da poter scegliere il server che desideri. Ciò ti fornisce una rappresentazione delle azioni disponibili; che include un link da seguire per l'azione di riavvio. Segui questo link e ti porta in un modulo in cui puoi specificare il tipo di riavvio. Si invia tale modulo e viene elaborato il messaggio per il riavvio del sistema.
Le idee chiave qui sono che non hai mai avuto bisogno di conoscere alcun URI, ad eccezione del segnalibro iniziale, e non hai mai avuto bisogno di sapere quale metodo dell'interfaccia uniforme usare, ad eccezione del segnalibro. Tutto il resto dell'impianto idraulico proviene dalle rappresentazioni fornite dal server.
Il tuo cliente (il browser) doveva conoscere il tipo di media delle rappresentazioni; per trovare i dati che descrivono i collegamenti e i metodi e per trovare i dati semantici da fornire all'utente. Tu stesso hai bisogno di familiarità con la semantica (cosa significa riavvio?), In modo da poter seguire il protocollo, ma non hai bisogno di sapere nulla sull'impianto idraulico.
Fielding, scrittura nel 2008
I should also note that the above is not yet fully RESTful, at least how I use the term. All I have done is described the service interfaces, which is no more than any RPC. In order to make it RESTful, I would need to add hypertext to introduce and define the service, describe how to perform the mapping using forms and/or link templates, and provide code to combine the visualizations in useful ways. I could even go further and define these relationships as a standard, much like Atom has standardized a normal set of HTTP relationships with expected semantics....
In altre parole, non si tratta solo dell'endpoint, ma anche del viaggio per trovarlo.
Does this way of doing things (resources with "methods" as well as data, sort of like OOP in API form) count as RESTful?
Quindi, usando l'esempio specifico di questa API, direi che no, non conta come RESTful. Il fatto che la risposta sia application / json, un tipo di media che non definisce uno standard per i link, è un grande segnale di avvertimento. Inoltre, sembra che tutte le informazioni sul corpo del messaggio da inviare all'host siano descritte fuori banda , piuttosto che all'interno delle rappresentazioni scambiate.
And, even if not, are any of the purported advantages of REST lost in APIs which follow this sort of design?
La cosa principale che è andata persa è la possibilità di modificare gli identificativi e i metodi di risorse utilizzati dall'interfaccia uniforme. Ad esempio, in HTML possiamo passare un modulo da GET a POST (o viceversa) semplicemente facendo la modifica appropriata nella rappresentazione; possiamo banalmente passare a un diverso spazio dei nomi URI perché il client sta solo seguendo il link come rappresentato nell'ipermedia.
Ad esempio, Wayback Machine funziona ; un ragno può eseguire la scansione degli endpoint sicuri nella tua API (e sapere quali sono sicuri per eseguire la scansione solo esaminando le rappresentazioni dei collegamenti), raccogli i dati, sostituisci tutti gli identificatori di risorse e rendi disponibili i risultati. Il client può seguire i link nella macchina del wayback con la stessa facilità con cui può farlo nell'API originale, una volta fornito il punto di partenza corretto.
one could very easily change it to POST /servers/{server_id}/actions/reboot/invocations,although it feels like a bit of a cheat.
REST non si cura di quale ortografia si usa per i propri identificatori. Sono opachi; qualsiasi significato in essi contenuto è fatto a discrezione del server e per il suo uso esclusivo.
Per quanto riguarda REST, la seguente riga di richiesta è del tutto coerente con una risorsa che riavvia un server
POST /5dc2a243-f00b-40df-84b2-dbed81d73331 HTTP/1.1
if this sort of pattern was repeated throughout the API, then this would make it RESTful
Si
even if there are endpoints which look like they are describing verbs or processes or actions rather than nouns/things/resources
Sì.
Il design URI è una preoccupazione completamente diversa da REST.