I am working on a system that have a RESTful web service that can manipulate it (the service allows all CURD operations), and a web client that displays the system's data(most of the client was written in jQuery). In the standard operation scenario there are a main server and at least one backup server of my system and so at least two RESTful web service.
So my question is in the case that my main server crashes, how can I make a client that was looking at the main server to now be looking at the backup server without any user manipulation?
Your best option is to have the client do absolutely nothing to deal with server failure. It's not the client's responsibility, and should never be. Server-side technologies like proxy servers and load balancers are best placed to handle server failures.
The most common approach is to move away from the "one primary server" way of thinking and instead create a cluster of servers, each of which could handle any of your REST requests. If your REST requests are stateless (and they should be) and can be routed to any arbitrary server in the cluster, then the failure of a server can be handled by using a load balancer in front of the cluster.
If the load balancer detects that a server is dead, it just pulls it out of rotation. This model also helps in scalability, because you can scale out your REST server layer by simply spinning up more servers in that layer and having them self-register with the load balancer.
You can also use DNS to insulate the client from server failure. Just change the DNS record point to the currently active server and modify it when the primary server goes down. However the TTL has to be very low to allow this technique to work in any reasonable time. DNS is better used to handle complete data center failure rather than node failure, but it's an option, albeit a fairly gross one.
