Summary

The core::0133::request-id-field rule flags Create requests as missing a client-specified ID field (e.g. book_id), but this creates false positives when request_id is used as an idempotency key per AIP-155.

Problem

AIP-133 allows client-specified resource IDs via fields like {resource}_id (e.g., book_id in CreateBookRequest).

AIP-155 recommends request_id as an idempotency key - a completely different use case:

• Purpose: deduplicate mutation requests from network retries
• Behavior: server returns cached response for duplicate request IDs
• Not a resource identifier

The linter strictly enforces AIP-133 and requires {resource}_id, failing to recognize that request_id satisfies the idempotency requirement.

Example

message CreateBookRequest {
  string parent = 1 [(google.api.resource_reference).child_type = "library.googleapis.com/Book"];
  
  Book book = 2 [(google.api.field_behavior) = REQUIRED];
  
  // Idempotency key per AIP-155 - NOT a client-specified resource ID
  string request_id = 3 [
    (google.api.field_behavior) = OPTIONAL,
    (google.api.field_info).format = UUID4
  ];
}

This triggers:

core::0133::request-id-field: create methods should contain a singular `string book_id` field.

Expected Behavior

The rule should not flag the missing {resource}_id when a valid AIP-155 idempotency key is present:

• Field name is exactly request_id
• Field behavior is OPTIONAL
• Field has UUID4 format annotation

Suggested Fix

Update the rule to check for request_id as a valid alternative when {resource}_id is missing.

References

• AIP-133: Create - Client-specifiedgh issue edit 1574 --repo googleapis/api-linter --body-file - <<EOF

Summary

The core::0133::request-id-field rule flags Create requests as missing a client-specified ID field (e.g. book_id), but this creates false positives when request_id is used as an idempotency key per AIP-155.

Problem

AIP-133 allows client-specified resource IDs via fields like {resource}_id (e.g., book_id in CreateBookRequest).

AIP-155 recommends request_id as an idempotency key - a completely different use case:

• Purpose: deduplicate mutation requests from network retries
• Behavior: server returns cached response for duplicate request IDs
• Not a resource identifier

The linter strictly enforces AIP-133 and requires {resource}_id, failing to recognize that request_id satisfies the idempotency requirement.

Example

message CreateBookRequest {
  string parent = 1 [(google.api.resource_reference).child_type = "library.googleapis.com/Book"];
  
  Book book = 2 [(google.api.field_behavior) = REQUIRED];
  
  // Idempotency key per AIP-155 - NOT a client-specified resource ID
  string request_id = 3 [
    (google.api.field_behavior) = OPTIONAL,
    (google.api.field_info).format = UUID4
  ];
}

This triggers:

core::0133::request-id-field: create methods should contain a singular `string book_id` field.

Expected Behavior

The rule should not flag the missing {resource}_id when a valid AIP-155 idempotency key is present:

• Field name is exactly request_id
• Field behavior is OPTIONAL
• Field has UUID4 format annotation

Suggested Fix

Update the rule to check for request_id as a valid alternative when {resource}_id is missing.

References

• AIP-133: Create - Client-specified IDs
• AIP-155: Request identification - Idempotency keys
• Rule documentation