-
Notifications
You must be signed in to change notification settings - Fork 12
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(specs): add dictionary
specs
#49
Conversation
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 overall.
Could you please add a small test for each endpoint please ? ;)
content: | ||
application/json: | ||
schema: | ||
$ref: './common/schemas/DictionaryEntriesResponse.yml#/dictionaryEntriesResponse' |
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.
Didn't we say that we wanted to avoid refs like this when possible ?
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 one is not pointing to the properties
, do you mean the ./
at the beginning?
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.
No I mean, I thought we should simply add the properties directly in the file without any ref, as it's done here for example : https://github.com/algolia/api-clients-automation/blob/main/specs/search/paths/synonyms/clearAllSynonyms.yml#L19-L26
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.
The same response is used in 3 endpoints, so IMO it made more sense to only have one definition. I can't remember if we had a discussion about this but I think we should reduce duplicate as mush as possible.
We could even have this generic response (updatedAt
, taskId
) as a common response for all of our clients. wdyt?
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.
Okay let's do this (same for deletedAt
and createdAt
maybe ?
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.
Could you list them all here?
I have a local branch that improve consistency between spec files, I can put it in this PR
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.
- taskID / updatedAt
- taskID / deletedAt
- taskID / createdAt
- hits / nbHits ?
- search / count / nbHits ?
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.
Thanks! I'll try to make them generic and find a good name D:
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.
馃憤
specs/search/paths/dictionaries/common/schemas/SearchDictionaryEntriesResponse.yml
Show resolved
Hide resolved
I did not did it for this PR since it was already big, I will do a PR right after with some tests for these (and some others) endpoints. wdyt? |
No problem :) . I just feel that I'm the only one to add tests until now ahah |
True D: |
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.
LGTM now :)
馃Л What and Why
馃師 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-194
Changes included:
dictionary
endpoint specsref
that were not correct馃И Test
CI :D