-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add AI Face next GA version #31023
Add AI Face next GA version #31023
Conversation
Next Steps to Merge✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge. |
Generated ApiView
|
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Breaking changes previously reviewed and approved in #29781 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. 👍
@@ -166,7 +166,7 @@ union ImageType { | |||
} | |||
|
|||
@doc("The liveness classification for target face.") | |||
model LivenessOutputsTarget { | |||
model LivenessDecisionTarget { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a retro breaking change. Shouldn't you use @rename versioning decorator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it's okay since it's mostly only affecting documentation. We are not changing the actual name inside payload.
BTW, this is some feedback from C# SDK review, but I think it worth to change it at REST level for better naming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rename
should work for intention to change it going forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's wait for the final design, we may need to rebuild a lot of models after the change.
API change check APIView has identified API level changes in this PR and created following API reviews. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
applying the patch: #31205 for v1.2
specification/ai/Face/examples/v1.2/FaceRecognitionOperations_FindSimilar.json
Outdated
Show resolved
Hide resolved
specification/ai/Face/examples/v1.2/FaceRecognitionOperations_FindSimilarFromFaceList.json
Outdated
Show resolved
Hide resolved
specification/ai/Face/examples/v1.2/FaceRecognitionOperations_FindSimilarFromLargeFaceList.json
Outdated
Show resolved
Hide resolved
...ai/data-plane/Face/stable/v1.2/examples/LivenessSessionOperations_CreateLivenessSession.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very close -- just need to get the form data parameters all listed separately.
{ | ||
"name": "Parameters", | ||
"in": "formData", | ||
"description": "The parameters for creating session.", | ||
"required": true, | ||
"type": "string" | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what you want here is the properties of CreateLivenessWithVerifySessionJsonContent
all listed as separate formData parameters. I'm not sure what you have to do in TypeSpec to get that to happen but hopefully @allenjzhang can help you get that figured out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean expanding each field in CreateLivenessWithVerifySessionJsonContent
as a part in MFD?
Something looks like
"parameters": [
{
"name": "livenessOperationMode",
"in": "formData",
"description": "Type of liveness mode the client should follow.",
"required": true,
"type": "string"
},
{
"name": "deviceCorrelationIdSetInClient",
"in": "formData",
"description": "Type of liveness mode the client should follow.",
"required": true,
"type": "bool"
},
...
{
"name": "VerifyImage",
"in": "formData",
"description": "The image stream for verify. Content-Disposition header field for this part must have filename.",
"required": true,
"type": "file"
}
],
This would be different from the current design. We put all fields inside json and serialize them into a string, and put them inside one part in MFD. I think there is no way to describe current design schema completely in swagger 2.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is what I meant, and when you say
We put all fields inside json and serialize them into a string
I think you mean "We require the user to put all the fields into an object and serialize that to JSON". AND the REST API gives no indication of this or what fields belong there. So a user trying to use the REST API would be completely stymied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense to me.
BTW, should we also change the name "VerifyImage" to camelCase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikekistler Following up on Han's question, should we use camel-case or pascal-case for the parameter names? i.e. verifyImage or VerifyImage? Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Camel case is probably best, as that is what we recommend for JSON. But we don't have formal guidance on field names in multipart/form-data so I think there is wiggle room here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! 👍
Thanks for all the fixes!
Waiting for service deployment, PR will be merged when all the backend work are ready. |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
Data Plane API Specification Update Pull Request
Tip
Overwhelmed by all this guidance? See the
Getting help
section at the bottom of this PR description.PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.
API Info: The Basics
Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.
Is this review for (select one):
Change Scope
This section will help us focus on the specific parts of your API that are new or have been modified.
Please share a link to the design document for the new APIs, a link to the previous API Spec document (if applicable), and the root paths that have been updated.
Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the
Generated ApiView
comment added to this PR. You can use ApiView to show API versions diff.Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
❔Got questions? Need additional info?? We are here to help!
Contact us!
The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.
Click here for links to tools, specs, guidelines & other good stuff
Tooling
Guidelines & Specifications
Helpful Links
Getting help
write access
per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositoriesNext Steps to Merge
comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.and https://aka.ms/ci-fix.
queued
state, please add a comment with contents/azp run
.This should result in a new comment denoting a
PR validation pipeline
has started and the checks should be updated after few minutes.fix #31108