Messaging queing systems like Rabbit/ActiveMQ give guarantee and delivery of the messages.Once sender sends a message on queue, its guaranted that message will be delivered to receiver.In developing REST service(or architecture) how message loss is prevented ? REST uses(in most cases) HTTP protocol.Is HTTP load balancer a solution?. As REST call will be synchronous,requester will quickly come to know success or response.
How message loss/message delivery guarantee is done in REST(without using MQ!) ? Is there any away of diing asynchronous processing using REST?
Yes Bill is right. REST based on HTTP protocol will be just request-reply with no reliability. I feel it is wrong to compare both asynchronous and synchronous mechanisms. if connection fails just retry again from the client side.
Thanks. I am thinking of using REST for logging/exceptions. Currently each interface sends JMS message on the queue(logging queue or exception queue).Then queue receiver on other side reads that and does JDBC insert.JMS was chosen as sender interface need not wait for log to be written to DB.Even if DB is down, JMS server is going to store the log messages. To achive this in REST(without using JMS), i think ,workaround is needed. Sender application 'retry if some problem" is not a good thing. Logs/Exceptions are secondary and sender application need not 'waste' their time periodically to check if other system is up.