Sending ACK after consuming the result of a RESTful web service?

Question

Consider a queue of items on server. The client then reads 10 queued items at a time using a REST web service. Naturally, when the client has consumed these items the server should remove them server-side.

Q: What is the best approach if we consider both robustness, network load and restfulness?

I can think of three possible solutions:

The client asks for new items. The server then...

1. sends item 1..10 (GET) and removes them immediately. Hopefully the items arrived at the client.
2. sends item 1..10 (GET), client sends ACK for 1..10 (DELETE), and the server removes the items.
3. sends item 1..10 (GET). Next time the client asks for 11..20 (GET), the previous items are removed on the server.

I believe both #1 and #3 violate the restful principle. E.g. Only the DELETE method may delete objects. However, they both avoid the data traffic for the ACK command.

Not sure what's best here. Perhaps there is an even better solution?

Answer 1

Here's the answer in votable format. I hope it helps clarify your options a bit more.

It's important in a REST-style architecture that the implementation of an API not change the implementation of any underlying protocols -- in this case it means that GET requests should be idempotent. While idempotent does not mean that the underlying resources can't change, or go away forever (AKA be deleted), having that happen as a direct or indirect result of a GET seems to not be in accordance with the spirit of the protocol.

Any system that guarantees delivery of a message requires some kind of handshake to single that the intended receiver successfully received the message -- if HTTP is the protocol in question, then that implies two requests. Even in the case where the behavior of GET were modified to lazily delete the resources, the handshake is still present -- it has just been shifted in time. Again, if HTTP is the protocol in questions, then using the existing methods of GET and then DELETE for the retrieval and deletion for that handshake seems best. The result shouldn't tax the network any more than any equivalent approach.