Perché dovrei usare JAX-RS REST invece dei normali servlet?

Un servizio di chat come api riposante è una BUONA partita!

Penso che le interfacce basate su risorse siano ancora un concetto molto importante di cui parlare. La risposta di cui sopra non è corretta, anche se ha più di 4 anni.

In generale, davvero NULLA è sbagliato nel costruire un'interfaccia di un server di chat come un'API ReST-ful orientata alle risorse. È assolutamente valido e un ottimo abbinamento per il principio. Ci sono anche esempi e pagine di tutorial là fuori, che usano questo come un esempio abbastanza semplice per mettere in risalto l'intenzione dietro l'API ReST-ful.

Perché è buono

Può essere un forum come un servizio o una chat "in tempo reale", non importa a questo proposito. Si riduce al modello di dominio.

ESEMPIO 1 (classica chat in tempo reale):

Sia un servizio di chat più elaborato, quindi è necessario creare una chat room. La chat sarà assegnata a lui / lei (l'oggetto utente) e al chatlobby che lo racchiude (appena assunto). Ora è possibile controllare la risorsa utente o la risorsa chatlobby o filtrare attraverso le risorse della chat tramite ulteriori parametri di query, cosa perfettamente valida.

Quale post ha recentemente visualizzato il client e cose del genere, purché non siano modellate nel nostro dominio del servizio di chat, non fa parte dello stato del server come menzionato in wikipedia. Questo è lo stato di "sessione" del client, il client indica quale parte della raccolta della risorsa del messaggio di chat vuole GET.

Quindi come osi dire che non combacia !! Per il forum come chat è ancora più semplice.

ESEMPIO 2 (forum come chat):

Un forum "chat" è un oggetto dominio e un commento su questo forum. Sicuramente quindi avranno bisogno di un identificatore univoco per consentire un identificatore di risorsa univoco (URI). Si può anche vedere che questo sembra abbastanza simile all'esempio precedente. Generalmente è un buon esempio, tuttavia si desidera attivare la chat.

Con un audit AOP ti vengono creati tempi di iniezione creati e modificati, puoi gestire l'autorizzazione ...

L'aspetto principale è che questo tipo di API rende necessario comprendere il dominio e le parti fondamentali che contano per l'utente, il consumatore o le applicazioni interattive in generale.

INDENZA E STATO:

È molto importante tenere a mente i principi. La voce Wikipedia dichiarata su ReST e il paragrafo sulla comunicazione STATELESS sono rivolti allo stato client, non allo stato degli oggetti dominio. Le risorse alias degli oggetti di dominio sono per definizione STATEFUL. Il paragrafo a cui si fa riferimento riguarda lo stato della sessione, non lo stato del dominio.

Se hai intenzione di sviluppare software aziendali, è fondamentale mantenere i confini e le razionalizzazioni.

IN A NUTSHELL:

Commenti e post, così come gli utenti sono esempi perfetti per un api riposante. Per questo motivo un servizio di chat è assolutamente perfetto per iniziare. Avere un identificatore seqenziale sicuramente non farà male. Andare oltre e provare a utilizzare i collegamenti per le relazioni (href) e definire la relazione tramite attributo relazione (rel). Quindi il client può utilizzare termini di dominio per consumare gli endpoint corretti. Il client può tramite questa tecnica (HATEOAS) esplorare l'intero grafico degli oggetti senza alcuna conoscenza degli oggetti del dominio stessi.

Spero che questo aiuti a chiarire, anche se questa è una voce più vecchia, l'argomento è ancora assolutamente recente.

Nota: i servizi web sono di livello elevato per servlet

Anche se possiamo scrivere servizi tramite servlet, usando i servizi web possiamo scrivere facilmente i servizi in modo strutturale.

Ci sono due tipi di servizi web 1) SOAP basato su 2) servizi web RESTful.

Differenza tra servlet e servizi web basati su sapone: i) questi servizi web non possono essere direttamente accessibili tramite browser. ii) Non è necessario scrivere un prototipo di webservice separato, che sta generando wsdl (che descrive i servizi web usando xsd), può essere pubblicato per i consumatori di servizi web iii) vengono introdotte soap ws per supportare facilmente SOA (Service Oriented Architecture)

Differenza tra servlet e restful webservices: i) Anche se i restful webservices funzionano direttamente su http / https protocal, fornisce altri metodi web oltre a ottenere, postare, eliminare. Che consente di scrivere facilmente codice strutturato basato su operazioni DB. ii) Poiché i restful webservices consentono di separare i pathparameters dai parametri di query, possiamo facilmente scrivere codice-codice a livello di classe e di metodo. iii) possiamo usare i plugin del postino come browser per controllare facilmente i rest-api. Possiamo facilmente aggiungere intestazioni, parametri del corpo, selezionare metodi diversi, tipo di contenuto insieme alla richiesta di un webservice restful richiesto sotto un URL. iv) possiamo anche fornire sicurezza per i rest-webservices facilmente attraverso la sezione header di http request msg's

Lo stato di sessione implicito nel server viene eseguito rispetto al concetto di REST di base :

The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource.

Non penso che un client di chat si adatti bene all'architettura REST. Se vuoi farlo comunque, dovresti provare a rendere la "posizione nel buffer della chat" una parte dell'URL REST (ad es. Dando ai messaggi un ID incrementale, e il client chiama / chatroom / 5 / getMessages / 37 per ottenere tutti i messaggi nella chat # 5 dopo il messaggio # 37