blob: f3703ef2b2afe75a477ff709dea10a9e62120d4d [file] [log] [blame]
<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>-&gt; 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>