- Notifications
You must be signed in to change notification settings - Fork 27
feat(specs): add dictionary specs #49
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
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:
dictionaryendpoint specsrefthat were not correct🧪 Test
CI :D