| <div class="wiki-content maincontent"><p>There are many ways to map JMS to REST...</p> |
| |
| <h2>Crappy non-REST</h2> |
| |
| <p>Send via </p> |
| |
| <structured-macro ac:macro-id="d7b1badc-1a83-45f4-aa96-bccc7d98258c" ac:name="code" ac:schema-version="1"><plain-text-body> |
| POST /queue/Destination |
| </plain-text-body></structured-macro> |
| |
| <p>Consume</p> |
| |
| <structured-macro ac:macro-id="a4aabcb2-1c9b-4fd2-8749-7afdc2abee82" ac:name="code" ac:schema-version="1"><plain-text-body> |
| GET /queue/Destination |
| </plain-text-body></structured-macro> |
| |
| <p>This is bad as the GET is not idempotent. We can add a user ID or use a cookie</p> |
| |
| <structured-macro ac:macro-id="c5a27fcb-bed0-4dc0-bfae-b2da55d827c2" ac:name="code" ac:schema-version="1"><plain-text-body> |
| GET /queue/Destination?jsessionId=.... |
| </plain-text-body></structured-macro> |
| |
| <p>though a caching proxy may keep returning the same message</p> |
| |
| <h2>Simple REST using 1 at a time delivery</h2> |
| |
| <p>Subscribe via</p> |
| |
| <p>POST /subscribe/consumerId/Destination<br clear="none"> |
| POST /unsubscribe/consumerId/Destination</p> |
| |
| <p>Then get messges via</p> |
| |
| <p>POST /nextMessageForMe/consumerId</p> |
| |
| <p>If you want to acknowledge messages you then</p> |
| |
| <p>POST /ack/consumerId/messageId</p> |
| |
| <h2>Batch message REST</h2> |
| |
| <structured-macro ac:macro-id="7d52776b-30cf-4924-a0b6-9962cc902061" ac:name="code" ac:schema-version="1"><plain-text-body> |
| POST lockNextMessage/consumerId?max=10 |
| </plain-text-body></structured-macro> |
| |
| <p>-> give back up to 10 message URLs</p> |
| |
| <p>GET message/consumerId/messageId</p> |
| |
| <p>acknowledge them via</p> |
| |
| <p>DELETE /consumerId/messages/messageId</p> |
| |
| <h3>Further options...</h3> |
| |
| <p>You can include ACK messages inside the POST; so the 2nd POST could include the ACKs - also you could return the batch of messages as well.</p> |
| |
| |
| |
| |
| </div> |
| |