I mentioned some reservations about REST support implemenation in the thread for Ext 3.0 RC2, many of which I see are fixed in 3.0.3. For example, the DataReader.update() no longer expects that server returns all or least some data with representation of the modified record. That's good. However, the DataReader.realize() is still broken. It still assumes that after creating the Record on the client, populating it with data, and sending this data to server, the server will send all this data back. But why server would do it? There is completely no point, it's only waste of bandwidth to send to the client the data that client already have. In some cases server can add/modify some of this data, then ok; but in many cases server won't. BUT, the realize method foolishly drops ALL local data and overrides it with data returned from server, see line 116 in DataReader:
rs.data = data;
This approach makes no sense at all. The same bug was already fixed in update method, why it is not fixed in realize method?
The only real difference is that in case of CREATE, in many cases the ID is generated by server, not by a client. So the realize method can expect the ID to be returned by the server in some cases. However, this ID doesn't have to be returned in response body. In RESTful services, it may be part of URL returned in Location header. So it's important to provide the extension point (per-class, i.e. to set it statically for all Ext.data.DataReader instances, and per-instance) for retrieving generated ID.
To sum it up, two things should be done:
1. Don't expect that server would return ANY data; in any case, don't throw away data already available on the client, instead override only those really returned by the server
2. Provide easy to use extension points for retrieving generated ID from server response.