Strong consistency means a successful write is immediately visible to standard reads and remains available across list, get, update, and delete operations. It prevents a newly created resource from appearing missing because replication has not reached every node. section 7.3.5
Choose the API shape according to the consistency the storage system can actually provide:
- Keep standard create methods strongly consistent whenever possible. section 7.3.5
- Use a custom import method such as ImportLogEntries when newly loaded data is necessarily eventually consistent. section 7.3.5
- Use a long-running operation when completion can be identified reliably after system-wide replication. section 7.3.5
Creating a chat room
After CreateChatRoom returns successfully, clients should be able to find the ChatRoom through list, retrieve it through get, modify it through update, and remove it through delete without encountering a replication-related 404. section 7.3.5
Listing 21.3 API definition for paging through single large resources
abstract class ChatRoomApi {
@get("/{id=chatRooms/*/messages/*/attachments/*}:read")
ReadAttachment(req: ReadAttachmentRequest):
ReadAttachmentResponse; #1
}
interface ReadAttachmentRequest {
id: string;
pageToken: string; #2
maxBytes: number; #3
}
interface ReadAttachmentResponse {
chunk: Attachment; #4
fieldMask: FieldMask; #5
nextPageToken: string; #6
}
For paged reads of a large resource, abort the request if the resource changes during paging; continuation tokens and field masks describe each consistent chunk. section 21.3.4
