Can somebody recommend the best way to simulate web service when it's unavailable. Is there a framework, able to record and notify the users when the web service is inaccessible ?
Thanks !
I've developed demos which have a failover in case of a 400 or 500 error code on the service response (due to lack of connectivity or firewalling on the customer side network). Basically, it has to be on the client code, though, where the logic parses the response and if it encounters unexpected/bad responses, has a default scenario to handle that situation.
It's not something I've done in production, but it does save some embarrassing situations in a skunkworks projects where your main application server is down or not responsive.
I saved the request of the client (soap request) in the database (byte array) , and saved the soap response also (if there is already a response). So, when the web service is unavailable, I search the last response existing in the database, which corresponds the request. If the remote service is not yet in operation, I used SoapUI API to generate a default response.
See also:
MockResponse
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 an application developed using AngularJS for front end and Java for back end.
issue i am facing is, if the user logs in to the application and searches for a particular data, there will be an API call with payload JSON sent to the server, in response we will get the data in JSON related to search parameters.
Problem here is user can open developer tool and copy the URL of the API and JSON payload and post the same data in Postman or DHC client and get the response JSON and more over he can alter data related to role and get search results that are related to other role/users.
My question is how to protect the API from directly calling form other sources and altering the payload.
There is no fundamental difference between requests sent by JavaScript client app by your browser and requests sent "manually" from any other tool like Postman or whatever. There is generally no security issue until all your requests are protected by any authentication mechanism like OAuth or simply with some secret API keys passed with each request (in this case these API keys should belong to the particular authenticated user only!).
Keep in mind, that security layer which protects your system from malicious or unsecured operations should lie on the server side only, not on client app. That means that everything which can be done from client app by a particular user can be done from any other tool (as you mentioned above) in "manual" mode by the same user.
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.
I'm using a jetty server to handle http requests. I would like to know if there is any way I can check if the response is successfully sent back to the client. Is there an error code or status that I can check, or an exception I can catch if the transfer to the client failed for any reason?
Thanks
Is there an error code or status that I can check, or an exception I can catch if the transfer to the client failed for any reason?
It sounds like you want the server to be able to know if the response was delivered completely to the client.
The simple answer is there isn't a way to know this. TCP/IP doesn't support this, HTTP does not support this, and the Servlet APIs don't support this.
In some circumstances, an exception may be throw if the server notices that the client has closed the connection early. But there are no guarantees that it will notice, or that it will result in an exception that will be visible to the application servlet code. Indeed it is quite likely that the close won't be noticed (if at all) until after the servlet call has returned.
If you want to implement some kind of "response delivered" acknowledgement for web pages, you could embed some "onload" Javascript in the webpage that sends an AJAX request back to the server. But then you have to consider the case where the user has disabled Javascript, or the original request was made by a non-browser application.
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.