YangCatalog / backend

YANG Catalog's REST API and internal module processing pipeline
https://yangcatalog.org
Apache License 2.0
2 stars 11 forks source link

Divide ycSearch #684

Closed dmytro-kyrychenko closed 1 year ago

dmytro-kyrychenko commented 1 year ago

@richardzilincikPantheon yeah, I checked they do not use redis. Also there could be a problem with moving them to yangSearch, because yangSearch has "/api/yang-search/v2" url prefix and this redisSearch has "/api" prefix. So yeah, the question is do we want to save the same prefix for these two endpoints and if so, maybe I'll need to move them to completely separate file

richardzilincikPantheon commented 1 year ago

Oh I see. Yeah I think we shouldn't really change the endpoint URLs. In the docs, these two endpoints are grouped together with some of the endpoints from compareModules under the "Services" section. The rest of the endpoints in compareModules are grouped together with the endpoints currently in redisSearch under the "Search" and "RPC Search" sections.

Splitting the files in the same ways would make the most sense to me, that way the whole services blueprint could have a prefix of api/services. Search and RPC Search endpoints can go in a single file as I don't see any kind of logical separation there. Could these two sections be merged in the documentation as well or do we want to keep them separate @SlavomirMazurPantheon?

I've also noticed that the endpoints in yangSearch appear to all be meant for internal use by our own frontend rather than as a public API. The name of this module should be changed to reflect that.