Feedback about how batch requests might work #117
Description
Just as a note, if you're redoing how this batch request works, I would find it much more useful if it didn't reference okhttp Requests, as I've already hooked up our own IConnection and IHttpProvider, and don't really want to use okhttp.
What would be ideal from my perspective would be a CustomBatchRequest extends BaseRequest with a method like public JsonObject post(BatchRequest batchRequest), where the BatchRequest is some trivially serializable to Json with a list of BatchRequestItems. But these BatchRequestItems could be subclassed for each request type when generating the rest of the classes automatically:
class UpdateMessageBatchRequestItem extends BatchRequestItem {
@expose public Message body;
}
Then IMessageRequest could expose toBatchRequest which would mean that you could build up these
batch requests in the same way as you'd use the rest of the GraphApi sdk.
My ideal usage would be something like
void markMessagesAsRead(List<String> messageIds) {
IGraphClient graphClient = buildMyOwnClient();
List<BatchRequest> requests = messageIds.stream().map(
messageId -> {
Message message = new Message();
return graphClient
.me()
.messages(mutation.getMessageId())
.buildRequest()
.postAsBatchRequest(message); // New method
}).collect(toList());
JsonObject response = CustomBatchRequest(graphClient).post(requests);
// Unfortunately we can't use a generic response like BatchResponse<Message> since we could have
// mixed request types.
// graphClient.getSerializer().deserializeObject() is useful when reading
}
Sorry if this feedback comes too late, or isn't too useful here.
AB#7707