What is the correct terminology for web service client app error handling paradigms?

I am trying to research error handling paradigms in web service client apps. I haven't found any good results on Google - perhaps I'm not searching using the right terminology. I will describe my imagined approach to error handling below. Can you name it?

Lets say our application is like iTunes but online. The user runs a JavaScript based client which interacts with a web service through AJAX. One of the things the user can do is to create 'albums' and then place 'songs' in them. At the API level this is represented by one API call to create a new album, and then one or more calls to associate an existing song with the new album.

Now a traditional client might pause the whole application until it has confirmed the album has been created. To make a snappier client we could optimistically assume the album creation API call will succeed, and immediately display the new album in the user's list. T开发者_C百科he user could start dragging songs into the new album even that the API call to create it is still pending behind the scenes. The API will catch up when it gets there.

In the unlikely case of an error (internet connection went down maybe) the app informs the user, pauses and retries the operation until it succeeds or the user quits. If the user quits, the application just forgets all uncommitted operations and the user loses a couple of actions.

What's the name for this kind of strategy? What's some good literature on the subject? Internet links?

I think what you describe can be seen as some kind of "reliable messaging". I'm not aware that it's used for ajax based applications, and from my point of view your design has some weak spots:

Assume you will not have only two API calls but three or more. Imagine how complex your error handling and reporting will become. A call to an API method should be some kind of atomic operation, so you should wait for the response if the future logic depends on it.

If you want your client to be snappier: Why do you want to execute the "new album" call anyway? If you manage the album updates in the client, you don't need to create the album before sending the contents of the album.

A good API for such a client is something different than a "on the server" API. Perhaps it could help you to have a look at Fowlers "unit of work" pattern. It's for databases, but in my opinion the idea also applies to your setting.