REST utilizza le funzionalità correnti del Web e applica alcuni principi su di esso per renderlo più efficiente. Usa i verbi HTTP standard per la comunicazione e aiuta la sua natura senza stato.Posso usare TCP in un servizio RESTful?
Tuttavia, è possibile che un servizio REST utilizzi il protocollo TCP per la sua comunicazione? Se sì, allora violerà i suoi principi?
HTTP è un protocollo basato su TCP/IP. Quindi quando usi REST stai già usando il TCP per la comunicazione. Ma se si desidera utilizzare REST su socket TCP puro, senza HTTP, quindi no, questo non ha senso perché REST è basato su verbi HTTP e intestazioni. Queste nozioni esistono solo nel protocollo HTTP.
Ma WCF è sviluppato in modo tale che cambiando solo i binding lo stesso servizio può funzionare con HTTP, TCP, IPC o altro protocollo, quindi vuol dire che queste funzioni WCF non sono supportate su Rest Servizio WCF. – funsukvangdu
È possibile utilizzare REST solo con HTTP. –
È assolutamente vero che REST dipende da HTTP? – MBen
Non è possibile utilizzare altri collegamenti eccetto Http per servizi basati su Rest. È dovuto al riposo è uno stile architettonico che si basa su un certo principio. Uno di questi principi è quello di prendere l'aiuto del protocollo stateless del web che è http, inoltre desidera utilizzare le parole Http come Get, Port, Put e Delete per utilizzare che non sono disponibili al protocollo TCP
Come già Darin answered, HTTP è un protocollo TCP con un sovraccarico che è esattamente ciò che viene utilizzato nella definizione RESTful. Quindi no, non è possibile rimuovere l'overhead HTTP.
credo che la tua domanda "Posso usare TCP per un'applicazione più veloce RESTful?" è correlato con la domanda "Perché così tanti siti web stanno utilizzando REST se HTTP è più lento di TCP puro?".
La verità è: HTTP è infatti più lento rispetto alla forma pura TCP binario, ma in più applicazioni, i tuoi utenti non noteranno la differenza perché il sovraccarico è davvero molto piccola e di solito il cliente farà solo un poche richieste al minuto.
Ad esempio: GET /posts?userId=5
Se la richiesta richiede più di pochi millisecondi per completare, quindi il problema non è nel protocollo HTTP. Il problema di prestazioni è correlato alla latenza della rete, con il codice lato server e il modo in cui si recuperano i dati dal database.
D'altra parte, se il codice cliente sta facendo migliaia di richieste al minuto, quindi questo singolo client noterà un problema di prestazioni relativo al sovraccarico HTTP. In questo caso, forse è possibile eseguire il batch di molte operazioni in un'unica operazione e ridurre la quantità di richieste di rete.
Se un singolo cliente ha davvero bisogno di fare migliaia di richieste al minuto, allora si può pensare di evitare REST e iniziare a cercare un altro approccio. Basta ricordare che SOAP può usare un binding TCP, ma le richieste hanno anche overheads per analizzare gli XML. Inoltre, SOAP è stato e HTTP è senza stato. Un approccio stateful è peggiore per la scalabilità.
Angolo leggermente diverso:
1. Non utilizzare WCF per creare servizi basati su REST. Usa Asp.Net WebAPI.
2. Solo per divertimento: se si desidera utilizzare i collegamenti TCP WCF tenendo presente i principi di "REST", è possibile creare un'API stateless basata su "risorse" anziché su una RPC tipica come quella.
[ServiceContract]
interface RestApi
{
Result Get(string id);
Result Post(string id, Resource resource);
Result Put(string id, Resource resource);
void Delete(string id);
}
In questo modo non è necessario definire un contratto diverso per ogni servizio e solo regolare le risorse per le diverse interazioni.
NOTA: Non sto suggerendo a nessuno di farlo: reinventa la ruota. Usa WebAPI se vuoi REST.
Non ho mai sentito dire che i "principi" di REST hanno lo scopo di renderlo più efficiente. –