azure-rest-api-specs
azure-rest-api-specs copied to clipboard
Azure
[Azure Event Grid] API Review
New API Review meeting has been requested.
Service Name: Azure Event Grid Review Created By: Javier Fernandez Review Date: 1/10/2023 1:00 PM PT PR: Hero Scenarios Link: Not Provided Core Concepts Doc Link: Not Provided
Description: Event Grid has new APIs to publish and pull (client connects to EG) events. We are planning to have a swagger for a first review during the meeting.
Detailed meeting information and documents provided can be accessed here For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here
Minutes of Jan 10 API Review
Link to API Design doc: https://microsoft.sharepoint.com/:w:/t/EventGrid/EQNBCnir-NJEqZucliuTAG0BHVwcbUyD9CkLZwa4BdsV1Q?e=dQeIbE
- Moving to a new model where events have "topics" (string) within a "namespace" (ARM resource).
- Will be added alongside existing Event Grid capability
- "Old" events do not interoperate with "new" events
- The "namespace" will be part of the domain for the service.
- Public preview in 1H23. Will support HTTP. AMQP support will come later.
- All operations are post actions since HTTP verbs do not map well to this event delivery architecture
- We don't want to send or receive bare arrays in request/response bodies
- But this is the cloud event standard. And we want to adhere to this (including the content-type).
- But use an object for request/response bodies not defined by Cloud Events
- There is no expectation of idempotency for these APIs.
- Should you use 429 for too many events in the payload? They don't -- too many events in payload is 413.
- Should include the standard Azure error response body.
- Probably want to drop the "charset=utf-8" from media type
- "locktoken" should be "lockToken" (camel-case)
- "maxEvents" -- use camel-case and query param is fine.
@jfggdl Can you please update on your progress to incorporate the feedback above and submit a PR for the REST API?
- Kishore and Balmukund
- Javier
Sent from Outlookhttp://aka.ms/weboutlook
From: Mike Kistler @.> Sent: Monday, February 6, 2023 6:00 AM To: Azure/azure-rest-api-specs @.> Cc: Javier Fernandez @.>; Mention @.> Subject: Re: [Azure/azure-rest-api-specs] [Azure Event Grid] API Review (Issue #21880)
@jfggdlhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjfggdl&data=05%7C01%7Cjafernan%40microsoft.com%7C714da81048bf47fdc7b208db084a76c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638112888137432469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hWgWFmvHlfBRQlk%2FfktQtMgxl4QDkhjp503LFHh05G8%3D&reserved=0 Can you please update on your progress to incorporate the feedback above and submit a PR for the REST API?
— Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fissues%2F21880%23issuecomment-1419126037&data=05%7C01%7Cjafernan%40microsoft.com%7C714da81048bf47fdc7b208db084a76c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638112888137432469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=31mmCkfkcCnn01G2%2BtZHL23pPlMggI7XuTqEBVfMbGU%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABWCNSN2CZZNOYFJ7DIYQLDWWD7WXANCNFSM6AAAAAAS5T4ZCI&data=05%7C01%7Cjafernan%40microsoft.com%7C714da81048bf47fdc7b208db084a76c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638112888137432469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5zbCXdBdNcncYsZnMLO7rcFAuTgAz7LFiZ9B7P%2FcPLw%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>
@mikekistler We have incorporated all the feedback in our service. We will raise a PR for swagger.
A new review including the TypeSpec has been scheduled here: https://github.com/Azure/azure-rest-api-specs/issues/23200
FYI, final TypeSpec is submitted here: https://github.com/Azure/azure-rest-api-specs/pull/23204/files
New API Review meeting has been requested.
Service Name: Azure Event Grid - Event Grid Namespace Review Created By: Javier Fernandez Review Date: 09/27/2023 09:00 AM PT Onboarding Record: https://dev.azure.com/azure-sdk/Release/_workitems/edit/13205 PR: https://github.com/Azure/azure-rest-api-specs/pull/25421 Hero Scenarios Link: Not Provided Core Concepts Doc Link: Not Provided
Description:
Detailed meeting information and documents provided can be accessed here For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here
Notes from API Review Meeting, 9/27/23
- Breaking Change tooling failed. We need to investigate what breaks if any were created by converting to TypeSpec.
- Shouldn't there be versioning tags for new features? Right now the TypeSpec is only for the preview API.
- Why explicitly specify content-type ?
- Why is the body named "lockTokens" and not "renewLockOptions"?
- Is there a convention for naming body parameters that we should recommend?
- tspconfig.yaml defines the version explicitly -- should not be doing that
- Need to fix the config
- And add the versioning decorators for things added in this new version
- Rename "renewLock" to "renewLocks" because it accepts multiple
- use camel case -- upper-case L
- Path segment "eventsubscriptions" should be either kebab-case (preferred) or camel-case
- But if the control plane path uses "eventsubscriptions" then maybe best to be consistent
- See comment in the PR about confusion on the type of "token" -- are these just strings, or a model, or what?
- Numerical enum -- this is unusual.
- Why reject an arbitrary values ? Maybe this is okay for preview but need to get feedback.
- Will the generated SDKs handle this? JS: "We'll see"
- Eliminate "ReleaseEvent" in enum value names.
- Will the release in 0 seconds value be removed ?
- No -- keep it to make clear that this is the default value.
failedLockTokens->rejectFailures??- Naming is hard. Use the preview to see if customers are confused by this
This looks good for preview.