È possibile utilizzare ReST su Websockets?

Sto pianificando di sviluppare un'applicazione di chat basata sul web che raccolga richieste RST, le traduca in XMPP e le invii a un server XMPP.È possibile utilizzare ReST su Websockets?

L'utilizzo di websocket per questo tipo di applicazione basata su chat sembrava promettente in quanto gli eventi (o le risposte) possono essere erogati in modo asincrono. Ma se utilizzo websockets come protocollo sottostante per trasferire le richieste dal browser, può ancora essere considerato un progetto di ReSTful? Se sì, come sono gli URI, i verbi (GET, POST ...), i parametri rappresentati nel messaggio websocket? Avvolgeteli in un xml/json e inviarlo?

Inoltre, l'architettura ReSTful indica che nessuno stato di sessione verrà memorizzato sul server. Ma qui in questo caso quando viene creata una sessione client XMPP, lo stato di questa sessione verrà memorizzato sul server (violando il vincolo stateless)

fonte

2012-11-14 Krishna Chaitanya P

Perché si desidera creare un'API REST sopra il socket? IMHO il vantaggio di un'API REST è di sfruttare le possibilità del protocollo HTTP standard come le richieste senza stato, i verbi semantici come GET, DELETE per costruire un'API che può essere facilmente compresa dagli sviluppatori (client). Poiché i socket non offrono verbi HTTP e così via, si costruisce un tipo di strato HTTP per socket che IMHO non è ragionevole.

Nel caso in cui si dovesse davvero costruire una cosa del genere, consiglierei di utilizzare il protocollo HTTP come progetto e implementare il protocollo socket come HTTP.

fonte

2012-11-14 07:20:04 saintedlama

Quindi, come si può ottenere una comunicazione in tempo reale con REST? L'idea di avere REST su WebSockets è più o meno legittima. Mi piacerebbe avere la semantica REST con comunicazione in tempo reale. Tuttavia, sto iniziando a pensare che queste due cose siano abbastanza incompatibili. – miguelcobain

@miguelcobain So che è molto tardi, ma l'intero concetto di REST è basato su richieste senza stato. Non c'è comunicazione in tempo reale in REST. – Davy8

@ Davy8 Quindi, vuoi dire che quando qualcuno sceglie di usare REST, non sarà mai in grado di ottenere aggiornamenti in tempo reale? Siamo bloccati con le vecchie tecniche di polling dei server basate sugli intervalli? – miguelcobain

Non capisco perché converti XMPP in REST e quindi esegui REST su WS. Il punto di WebSocket è di portare il protocollo XMPP direttamente al browser, evitando così tutti i problemi di traduzione.

Esistono librerie JavaScript in grado di comunicare XMPP dal browser al server. Tutto ciò di cui hai bisogno è proxy del traffico XMPP da WS su TCP e poi direttamente sul tuo server XMPP. Kaazing has a gateway che ti permette di farlo.

Se si desidera utilizzare l'open source, è necessario scrivere una libreria XMPP JavaScript. Ci sono esempi che mostrano come scrivere una libreria JS per protocolli semplici. Devi solo trovarne uno ed estendere il concetto al protocollo XMPP.

Quindi, per ricapitolare, qui il modo in cui l'architettura apparirebbe:

Il codice client XMPP < -> XMPP JavaScript Library < -> WebSocket su HTTP < -> WebSocket a TCP Proxy < -> XMPP Server

dove il codice client XMPP e la libreria JavaScript XMPP vengono eseguiti nel browser e il proxy WS-TCP insieme al server XMPP sono tutti sul lato server.

fonte

2012-11-16 02:01:31 Axel

Non c'è XMPP sul lato client. L'idea è di eliminare la necessità per uno sviluppatore web di comprendere/avere una conoscenza di XMPP. Ha solo bisogno di avere un'idea di messaggistica istantanea e presenza. Esempi: per creare una sessione lo sviluppatore web nel suo widget/applicazione invia un POST a qualche URI, con il suo nome utente e password, e il "WS to TCP Proxy" nei tuoi termini lo convertirà in un messaggio XMPP e lo invierà al server XMPP. –

Un altro esempio: Per aggiornare la presenza, un PUT viene inviato a un URI say/proxy/presence e il proxy lo converte in un pacchetto di presenza XMPP e lo invia al server XMPP. Allo stesso modo un messaggio: un POST viene inviato a URI/proxy/messaggio e il proxy lo converte in un messaggio XMPP, lo invia al server XMPP che a sua volta lo consegna al destinatario. Il motivo dell'utilizzo di REST è che sarà facile per lo sviluppatore web che utilizza l'API creare applicazioni di chat. –

XMPP non è difficile da capire, a seconda della facilità d'uso della libreria client javascript XMPP, l'API è in realtà più facile da usare e più robusta rispetto al wrestling con REST. Le persone tendono ad avere paura di ciò che non capiscono e quindi cercano di attenersi a ciò che sanno, in questo caso REST, anche se lo rende più complicato e inefficiente. Ti suggerisco di dedicare alcuni minuti per vedere quanto sia facile utilizzare XMPP. Non c'è davvero alcuna ragione per introdurre un sacco di inefficienze e overhead extra convertendo XMPP in REST. È molto più lavoro e limiterà la tua creatività. – Axel

Sì. È possibile utilizzare REST su WebSocket con libreria come SwaggerSocket.

fonte

2013-03-26 11:50:40 jdelobel

No. Swagger è solo HTTP su websocket, non proprio REST. – gentimouton

@gentimouton Tutto ciò che ha detto è che è possibile utilizzare Swagger per interfacciarsi con i servizi REST. Non ha mai dichiarato che lo swagger era REST ... Si usa HTTP per interfacciarsi con REST, questo è il punto. – Slight

REST è uno stile architettonico che non impone un protocollo. Quindi sì, puoi fare REST con Web Sockets, REST con HTTP e REST con FTP se lo desideri.

Il motivo principale per utilizzare HTTP è che è facile e abbastanza semplice comunicare con qualsiasi componente o linguaggio di programmazione tramite HTTP e anche perché HTTP supporta ambienti distribuiti con più intermediari: proxy, firewall ...; Quindi puoi distribuire il tuo servizio su qualsiasi topologia e chiunque sarà in grado di accedervi.

mio sproloquio: Se sei un RESTliban e tesi di Roy Fielding è la fonte della verità, i verbi sono mai riconosciuti come parte della semantica. Gli URI sono semantici. L'utilizzo di verbi diversi per diverse azioni è stata un'elegante evoluzione di REST su HTTP, ma non fa parte della "verità". È possibile controllare lo scenario di rest over HTTP evaluated by Roy in chapter six della sua tesi. Nessuna menzione ai verbi. E notare che è uno scenario di valutazione, non la specifica.

TLDR;

Se sono necessarie comunicazioni bidirezionali in tempo reale via Internet e il client è un browser Web, la scelta migliore è Web Sockets. È quindi possibile implementare un protocollo a livello di applicazione sopra i socket Web per implementare un servizio Web RESTful.

fonte

2014-11-20 12:59:44

Ho appena individuato un nuovo argomento sul blog di un'azienda che fornisce soluzioni cloud e "Server-end/Service as a Platform" (SaaS) per i giochi.

Non sto pubblicizzando questa azienda, né li ho usati, quindi non so nemmeno quanto siano buoni o cattivi.

Tuttavia, essi spiegano molto chiaramente ragioni e quali sono i vantaggi di utilizzare WebSockets in REST avere una lettura su their blog

fonte

2016-02-05 20:30:47 Briksins

RESTO stile architettonico presuppone principalmente un 2 entità vale a dire. client e server.

Mentre ci spostiamo di più verso il web in tempo reale e lo sviluppo di sistemi reattivi, WebSocket inizierebbe in maniera prominente a sostituire l'utilizzo delle API REST.

WS consente il push e il pull dei dati che elimina il concetto di server e client.

STOMP, AMQP, XMPP possono essere utilizzati come protocolli di messaggistica.

I dati stessi possono essere i buffer del protocollo JSON o Google o forse Apache Avro.

WebSockets non è legato ai server Web, ma può essere sviluppato in app stand-alone come app mobili o anche applicazioni desktop.

fonte

2016-08-20 16:00:58 Rohitdev

Capisco che questo post sia molto vecchio, ma volevo intervenire un po 'di più sulla nozione che "Quindi, se scelgo un'architettura REST, perdo la possibilità di comunicazioni in tempo reale?".

In una parola, no. Una serie di implementazioni di stile REST che ho avuto esperienza con l'utilizzo di REST per compatibilità, rilevabilità e come mezzo per scalare su diversi dispositivi all'ombra di IoT.

Tuttavia, oltre a utilizzare WS in aggiunta a REST per facilitare la trasmissione quasi in tempo reale. Ci sono anche un certo numero di astrazioni che aiutano veramente con questo e ti permettono di concentrarti sulla costruzione dell'API e decidere come operare i componenti RT delle applicazioni che consumano.

Suggerirei di dare un'occhiata a cose come Tibco Smart-Sockets o SignalR se stai cercando di costruire un'API REST e vorrei evitare di ricreare la ruota per le tue esigenze RT.

fonte

2017-12-19 04:42:06 iHazCode

ho creato un progetto che aggiunge callback alla funzione di presa di invio web: https://github.com/Modern-Edge-Software/WebSocketR2

gli ID dei messaggi sono stabiliti in modo che il cliente può implementare callback.Gestisce i tentativi dei messaggi dopo i timeout e si riconnette al server se la connessione viene interrotta. È quindi possibile strutturare il carico utile come RESTful come si desidera aggiungendo verbi e percorsi.

Questo è simile a quando uno studio di video gioco usa UDP per raggiungere le velocità di cui hanno bisogno, ma il loro codice di rete implementa un sacco di TCP come le caratteristiche di affidabilità.

fonte

2018-01-28 14:20:28 Neo

È possibile utilizzare ReST su Websockets?

risposta

Problemi correlati