Server asking the Client for information?

Question

In a client-server system, is it considered good architecture for a server method to "ask the client" for more information? If so, what's the best way to design such a scenario? Is there a "pattern" for this?

For example, suppose the end user selects a set of records they want to delete in the client UI, then the client makes a "delete records" call to the server with the set of records as a parameter. Then the server finds a subset of those records which are "special" in some way and thus need to be confirmed by the user. Is it appropriate for the server to somehow "call back" to the client to a method called "confirm records" while still continuing the original call from the client to the server?

And what about more complex server calls that could require a long "dialog" between server and client?

Answer 1

Some sort of reply that say "Records x, y and z were not deleted, try again with I_RELLY_WANT_TO set to delete them" would seem like a reasonable solution to me.

General pattern; don't ask, do stuff and report back, let the client decide what to do next. This could be done in the context of a persistent connection as a form of dialog.

Not really my field so... add 64mg NaCl

Answer 2

A callback like that reverses the role of the client and server. In lots of these types of architectures, the client has no capacity to listen to requests. If it does, you're starting to look at P2P kind of system. Perhaps something like this might work.

client code: 
  special_records = server.deleteRecords(records)
  server.deleteSpecialRecords(special_records)

server code:
  def deleteRecords(records):
    special_records = detectSpecialRecords(records)
    reply(special_records)
    actuallyDeleteRecords(records - special_records)

So the first call to deleteRecords would return a list of these special records that need to be deleted explicitly. Hope this helps.

Answer 3

I think that kind of arrangement is totally fine. There's nothing preventing the server from replying with a query to the client for more information and for the client to provide it. As long as the socket connection is open, you have free reign to send messages back and forth.

I've seen an arrangement where the client sent a message to the server and after that didn't do much more than be a small layer above stdin/out and the file-system on the local machine as the server controlled it. It worked fine and was very fast.

Answer 4

The client is sending a list of files to delete, right? Just let the server reply with a list of success statuses, indicating which file was deleted, which one was not, and, maybe, why it was not deleted (doesn't exist, no permission etc).

If the common case is that all files are deleted successfully, maybe start off the response with a status field that indicates whether all files were deleted, or whether the client needs to actually evaluate the status codes to see how the operation has gone.

With this response, the client should be able to update its view on the state of the server, at least with respect to the files that had been selected for deletion (ie, remove from the UI those files that were deleted successfully, but also those which didn't exist any more; also, maybe indicate those files that the server couldn't delete because of missing permission accordingly).