I have a RESTful web Service that provide function of returning some data whenever a client send GET requests to ask for it:
#GET
#Path("/{deviceId}")
#Produces(MediaType.TEXT_PLAIN)
public String getDataResource(#PathParam("deviceId") long id){
return dataService.getData(id);
}
And the flow for this case would be the client sends request -> the web service returns value. But I want to ask that is it possible that the web service will automatically send response to the client when ever it has new data change inside of it? That means it not need to wait for the client to send request to ask for it. Because I would like to establish a communication between a client and some services running on an Application Server so that the client can always receives the newest data from the Application Server, so I think RESTful web Service can be a solution for it. And in oder to be ensure that the newest data will be transfered to the client side, so the server has to send to the client, not wait for the client to ask for it. Is RESTful web service provides any function like this?
Thank you all!
Is RESTful web service provides any function like this?
No. Not in the context you're asking for.
As answered before, the client could periodically poll for updates on the server. This is usually common option.
Another option - the original server posting updated on the "client". The client then becomes server itself. Viable, if you can expose services on the "client" side.
Maybe what are you looking for are web sockets. It is a long-lasting connection from client, where the server could keep returning data as they come.
There are some books around but you could search the net for more resources depending on the framework you use
You can implement notification system(observer pattern), so that client will poll the server in certain interval and any state change, it can get the result.
You may use the Schedulers to push the data to the client in a certain intervals.
Related
There is a client to my server, which is calling a GET API to know all updates regarding a particular thing very frequently (let's say once every 5 seconds). Due to this there is unnecessary network calls are landing on my server even if I don't an an update to share.
I reached a decision to replace above approach with web-hooks, where I'll call there POST API whenever I have an Update to share instead of letting them put unnecessary load on my server.
What I understand about Web-hooks:
A web-hook is like a reverse API which POSTs the updates to the server (The client which was calling our application frequently to know/GET updates).
My client has to implement a Web-hook client, which is basically a POST API, I'll be calling whenever there's an event/update to be shared.
I need to call their POST API using REST template wherever there's a new event.
What I don't understand:
Is there anything called a Webhook server? If yes, how do I create/implement it? Any references?
Is it just a reverse API, or is there anything special which both the server and the client needs to handle?
Webhooks are usually used to notify other service that some event occurred on your side. This is made by standard HTTP request sent to some URL.
There is no specific thing like Webhook Server. This is standard application that sends request to someone proactively.
Should both services communicating with webhooks handle something special - this depends on your architecture, there is no "standard" here. You can implement any sort of retry or mechanism to validate that the other side received the information. Im most cases it is assumed that webhooks should be idempotent, so if two same webhooks are sent, the other side should not repeat their action.
I have rest client API accessing data through /read endpoint from my server. However, I have an internal batch service that calls my server's /write endpoint which updates the data. So from time to time the data from the server gets updated. How will I tell the client that the data is updated and ask it to call the /read endpoint again to get the latest data?
Below is a highlevel diagram on the scenario.
Try learning webhooks? Basically, the client will "subscribe" to your webhook, or to make it easier, the client will provide an endpoint to the server. Whenever there's an update, your server just sends a request to the client. The client should simply call a service that, whenever it receives a request from the webhook, fetches read.
It basically goes like this
Client subscribes to server
The client gives the server an endpoint /updateAvailable
When there's an update, the server sends a request to client's endpoint /updateAvailable
'/updateAvailable' invokes a service that calls on '/read'
The '/updateAvailable' endpoint could invoke a service that updates content. Let's say the request sent has a parameter
{
"updateFound":true
}
So whenever the client's '/updateAvailable' is called and receives a request, you do something like this (pseudo code)
if (updateBody.updateFound.message=true)
then call read()
Edit
By creating an endpoint for client, you can also do automatic updates. So client has an /updateAvailable endpoint. The server sends the update to the /updateAvailable endpoint, which from the client side invokes whatever service is used for /read
There are two solutions for your question:
Using timer on restful client to request to restful server in every N seconds/minutes... However, it's really bad idea because it has to request to server many times even though there's no updated data.
Using third party publish-subscribe-based messaging protocol solutions to implement push notification feature whenever there is new data updated. These solutions are: Google FCM,MQTT,AMQP
I am currently trying Java Jersey 2.23.2 for my restful service
When both of the web client and tomcat web service runs on the same device, The session was handled perfectly.
However, when the an external client (another website) that runs on a different machine, there will always be new session introduced after an API call instead of sticking to just one session.
Is there anyway I could let the external client to call the webservice just like the local client does?
I can assume that your remote client does not care about JSESSIONID cookie. When session created, server sends HTTP header Set-Cookie with it.
Client must take it and then send it back with each subsequent requests.
All browsers do it automatically.
But as long as your client is another service it needs to care about it.
For a web service application, I would like for the server to be able to notify the clients about some events. When a client is launched, he calls one of the WS methods to get some information it needs. Then the server, that stores this information, listens continuously for changes on these information and if there is a change, it notifies the concerned client.
I don't know if a web service is a good solution to my problem? I don't know how it may work concerning the TCP connections, since the server may notify a client after a very long time.
What would be the best architecture to solve this kind of issue?
Thanks
EDIT: I've looked at some discussions that propose to use Comet, but if you think there are simpler and more convenient solution, please let me know. Since I'm starting this project from scratch, I have no limitations.
I can also use a polling model where the clients periodically poll the server for the information they need, but then I need to take into account the load that this model may create on the server. I don't know if web services can support such a load when there are a lot of clients.
I've also looked at the asynchronous functionality provided by Servlet 3.0 but I don't know how it may solve my problem.
Without polling: sockets
With polling and webservices: u should use etag (html).
When a client polls he sends a request with an etag. webservice responds either with 200(ok) and data or 304(not modified). 304 has no body => less trafic
Instead of client polling the server, you could implement a callback method on the client so that when ever server want to publish some changes to the client, the server can use the callback method provided by the client.
I can think of one the two approaches below using web services solution:
Callback: When client invokes the server it leaves its call back url and a id, say correlation id. When the server wants to respond back to the client it will just use the call back url to notify. The Server can use a variety of approaches to process the request asynchronously. Your client need not be a webservice for this, but it should be capable of accepting requests (callback). It can be a servlet etc.
Polling: When client makes a request to the server it receives back a id, say requestid. After specified interval client polls the server with this request id to fetch a response. A reasonable timeout and polling interval based on the processing time would be required.
I have the following requirement:
I need to create a socket server that listens fro incoming requests. The socket clients are written in C. The clients send JSON data.
The client input needs to be redirected to different sources. for example there might be a need to call an internal or external web service(SOAP, JAX-WS).
My question is, what is the best way to achieve such a communication?
I would implement the redirecting service as an observer and notify him when your observable (the socket server that listens) is called. If you're not familiar with that pattern, have a look at http://en.wikipedia.org/wiki/Observer_pattern. You basically keep up the information flow by pushing your information further down the chain of processes instead of pulling it actively by your redirecting service.
I hope you didn't need any help with the SOAP, JAX-WS stuff - your requirement doesn't change anything compared to the way you would normally implement such a service. (If you're as lazy as me, go with the wsimport commandline application ^^)