feat: add full clients architecture init

[damcou]

Add full search client architecture init

Added:

• Search Client
• Personalization Client
• Recommend Client
• Query Suggestions Client
• A/B Testing Client
• Analytics Client
• Insights Client

Won't be added for now (but added in JIRA)

• Crawler Client
• Monitoring Client
• Usage Client
• Light JS Client

[shortcuts]

I did not check the endpoints in detail but looks good overall!

[DevinCodes]

Quick question: would this generate a separate API client for each API, or would they still be part of the same package but in a different class?

[damcou]

Quick question: would this generate a separate API client for each API, or would they still be part of the same package but in a different class?

The goal is to have a class generated for each API Client (Search, Perso, Recommend, Analytics, etc...) in the same package. I created the first spec files to stick to the REST API list you mentioned during the last meeting (https://www.algolia.com/doc/api-reference/rest-api/)

[bodinsamuel]

This seems better like this, however I think we should abstract a little bit more and remove the ref of client in the specs. Those are OpenApi not necessarily made for client.

I also think some hierarchy are inverted, schemas and responses can hardly be reused accros APIs.

I would go for somethings like this:

 > specs
   > search
     > common
       parameters.yml
       
     > paths
       > indexes
         getObject.yml
         
       > dictionnaries
     spec.yml
     
   > recommend
   > abtesting
   > perso
   > query_suggestion
   > common

wdyt?

[damcou]

This seems better like this, however I think we should abstract a little bit more and remove the ref of client in the specs. Those are OpenApi not necessarily made for client.

I also think some hierarchy are inverted, schemas and responses can hardly be reused accros APIs.

I would go for somethings like this:

 > specs
   > search
     > common
       parameters.yml
       
     > paths
       > indexes
         getObject.yml
         
       > dictionnaries
     spec.yml
     
   > recommend
   > abtesting
   > perso
   > query_suggestion
   > common

wdyt?

You're right, it looks better that way, I reorganized the folders

[shortcuts]

I think we have mixed commons here:

• search/common/responses/common.yml
• search/common/parameters.yml
• search/common/schemas/ErrorBase.yml

Those are common to all the API clients.

Other than that, LGTM :D

[damcou]

I think we have mixed commons here:

* [search/common/responses/common.yml](https://github.com/algolia/api-client-automation-experiment/blob/feat/APIC-181/full-specs-init/specs/search/common/responses/common.yml)

* [search/common/parameters.yml](https://github.com/algolia/api-client-automation-experiment/blob/feat/APIC-181/full-specs-init/specs/search/common/parameters.yml)

* [search/common/schemas/ErrorBase.yml](https://github.com/algolia/api-client-automation-experiment/blob/feat/APIC-181/full-specs-init/specs/search/common/schemas/ErrorBase.yml)

Those are common to all the API clients.

Other than that, LGTM :D

Ah shit, good catch :p

[millotp]

Looking good ! I like the new structure, however there are issues with duplicate endpoints, I did not write them all but some files need to be merged like:
settings.yml:

get:
  ...

put:
  ...

[shortcuts]

I think the content of specs/common/responses/common.yml should be in specs/common/parameters.yml

[shortcuts]

securitySchemes can be a file

[shortcuts]

This seems like a good start, I guess we will fine tune/discover details once implementing the endpoints!

GG