1

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?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
l33t
  • 18,692
  • 16
  • 103
  • 180
  • It might be useful to outline the proposed requests/responses between client and server in more detail. For example, if the client were to "ask for new items" I would assume **it** would issue the `GET`, the server would respond (`200 Ok`???), and there would be no confusion about whether or not "the items arrived at the client". The way the question is posed, it does not sound like you are describing a REST-style interaction. So perhaps I am missing something. – toddsundsted Dec 23 '11 at 18:03
  • Sure. But if the server responds 200 ok, that piece of information must travel to the client too, right? Just because the server outputs data doesn't mean the client received it, or? – l33t Dec 23 '11 at 22:04
  • 1
    No, you're right. That's why `GET` should be idempotent, which is what is problematic for 1 and 3. The common approach I've seen is to follow the `GET` with a `DELETE`, which would only be issued if the `GET` was successful. But that's two round trips. So you're looking for something that could be a retrieve-and-delete with guaranteed delivery to the client? – toddsundsted Dec 23 '11 at 22:23
  • I believe that's the answer I was looking for. #2 it is. – l33t Dec 23 '11 at 22:39

1 Answers1

0

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.

toddsundsted
  • 6,225
  • 2
  • 21
  • 13