Skip to content
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

[Cogs Face] Align with latest released version of Face API with million-scale features. #3552

Merged
merged 16 commits into from
Aug 1, 2018

Conversation

lebronJ
Copy link
Contributor

@lebronJ lebronJ commented Jul 31, 2018

(I am one of the main devs working on Face API and Face containers.)

This is to align Face API swaggers with latest published version with million-scale features.

  • We have locally generated AutoRest SDK and written more tests to ensure all functionalities work.
  • This is also to catch container SDK preview with relatively high priority.

===================================================================
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

  • The title of the PR is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
  • If applicable, the PR references the bug/issue that it fixes.
  • Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

@lebronJ lebronJ requested a review from yangyuan as a code owner July 31, 2018 04:57
@azuresdkci
Copy link
Contributor

Can one of the admins verify this patch?

@AutorestCI
Copy link

AutorestCI commented Jul 31, 2018

Automation for azure-sdk-for-python

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-python#3011

@AutorestCI
Copy link

AutorestCI commented Jul 31, 2018

Automation for azure-sdk-for-node

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-node#3241

@AutorestCI
Copy link

AutorestCI commented Jul 31, 2018

Automation for azure-sdk-for-ruby

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-ruby#1519

@AutorestCI
Copy link

AutorestCI commented Jul 31, 2018

Automation for azure-sdk-for-java

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-java#2270

@AutorestCI
Copy link

AutorestCI commented Jul 31, 2018

Automation for azure-sdk-for-go

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-go#2374

Copy link
Member

@yangyuan yangyuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

}
}
},
"/largepersongroups/{largePersonGroupId}/persons/{personId}": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just double confirm, the paths are not case sensitive right?

Copy link
Contributor Author

@lebronJ lebronJ Jul 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, at least the generated .NET SDK works well. I'd like to append a minor commit to unify them to lower-case.
(BTW, the parameters inside {} are actually user-provided variables, rather than part of path.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I bring this up because I saw: "/largepersongroups/{largePersonGroupId}/persons/{personId}/persistedFaces/{persistedFaceId}"
For parameters, lowerCamelCase is good enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thanks.

@lebronJ
Copy link
Contributor Author

lebronJ commented Jul 31, 2018

@annatisch, I think this is good to merge, thanks.

},
"get": {
"description": "List all faces in a large face list, and retrieve face information (including userData and persistedFaceIds of registered faces of the face).",
"operationId": "LargeFaceListFace_List",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this operation ID should be changed to "LargeFaceList_ListFaces"
This would make it more consistent with the other operations like "LargeFaceList_GetFace" and "LargeFaceList_DeleteFace" etc.

Alternatively you could rename all of them: "LargeFaceListFace_Delete", "LargeFaceListFace_Get" etc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Thanks for pointing out this! Fixed with the latest commit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@annatisch Also updated our generated .NET SDK and all works.

"/largepersongroups/{largePersonGroupId}/persons/{personId}/persistedfaces": {
"post": {
"description": "Add a representative face to a person for identification. The input face is specified as an image with a targetFace rectangle.",
"operationId": "LargePersonGroupPerson_AddPersonFaceFromUrl",
Copy link

@huxuan huxuan Aug 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems this is not consistent with LargePersonGroupPerson_Delete/Get/UpdateFace. Maybe AddFaceFromUrl? But since the conventional PersonGroup also have this problem, I think it is OK to change it in a different pull request, but maybe it is better to align them before the release of breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it in this PR since it is tiny and new PR does take longer.

},
"get": {
"description": "List all persons in a large person group, and retrieve person information (including personId, name, userData and persistedFaceIds of registered faces of the person).",
"operationId": "LargePersonGroupPerson_List",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we prefer LargeFaceList_ListFaces then how about this? Besides, we also have LargePersonGroupPerson_Create/Get/Update/Delete.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using LargeFaceList_ListFaces is to be differentiated with LargeFaceList_List which refers to list large face lists. I guess you are thinking about the pattern of LargeFaceListFace_xx for face level operations. Yes, it's another pattern while my thought is the SDK could be more friendly to user if it uses same level as API reference, where LargeFaceList operations are all inside LargeFaceList section, without another level of LargeFaceListFace section.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I am think about using LargePersonGroup_ListPersons to align with LargeFaceList_ListFaces, but I think it is OK if we keep following the structure of API reference.

@annatisch
Copy link
Member

@lebronJ - LGTM
Last question - I see the operation LargePersonGroupPerson_Create returns a Person in the response, whereas the other two create operations (LargePersonGroup_Create, LargeFaceList_Create) don't. I'm guessing this is intentional?

@huxuan
Copy link

huxuan commented Aug 1, 2018

@annatisch, Yes, confirmed. It is compatible with our service and the reason is that the LargeFaceListId and LargePersonGroupId is specified by the customers while PersonId is auto generated by our service. So we need to return the generated PersonId to the customers but no need to return anything for LargePersonGroup and LargeFaceList creation.

@annatisch
Copy link
Member

Thanks @huxuan - let me know if you are finished reviewing internally and I can merge.

@jhendrixMSFT
Copy link
Member

@AutorestCI regenerate azure-sdk-for-go

@huxuan
Copy link

huxuan commented Aug 1, 2018

Hi @annatisch and @jhendrixMSFT, the internal review already finished before sending this pull request. Please feel free to move forward! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants