# Exposing elastic search query APIs at a public endpoint **URL:** \ **Category:** Elasticsearch\ **Created:** [June 10, 2014, 7:03am UTC](https://discuss.elastic.co/t/exposing-elastic-search-query-apis-at-a-public-endpoint/18006 "2014-06-10T07:03:08Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Pradeep\_Narayan](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@Pradeep\_Narayan](https://discuss.elastic.co/u/Pradeep_Narayan)\ **Post date:** [June 10, 2014, 7:03am UTC](https://discuss.elastic.co/t/exposing-elastic-search-query-apis-at-a-public-endpoint/18006/1 "2014-06-10T07:03:08Z")
Hi - We are designing a system for reporting and are planning to use Elastic search as a backend. We want to expose reporting in such a way that users can build custom reports on top of their data without us coming in their way. One way to do this is to expose elastic search query APIs through our public endpoints. The other option is to use an abstraction language which get translated to elastic search queries in the middle tier. The latter option allows us to control what runs on ES but can become restrictive in terms of how much we expose the rich query mechanism of ES using the abstraction layer. I would like to know if there is a known design pattern to solve this. How have users of elastic search addressed flexibility vs. control? Regards, Pradeep -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/7b09e135-578d-420a-9dc6-da503e4b3163%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7b09e135-578d-420a-9dc6-da503e4b3163%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [June 10, 2014, 7:34am UTC](https://discuss.elastic.co/t/exposing-elastic-search-query-apis-at-a-public-endpoint/18006/2 "2014-06-10T07:34:07Z")
It depend on your requirements and your product strategy - both is possible with pros and cons: - are your users proficient in a report language? Do they already write report specs in a "standard" report language? Do you want to support this report language standard? Do you like to share report standard language mapping to ES with the ES community? Then, try to find out if you can translate report language to ES domain language. - are your users fond of ES? If you open the access by proxy to the \_search backend, you are independent of any kind report language, but your users must learn by an extra step how to formulate Elasticsearch queries (and they could also formulate "bad queries" which are challenging ES cluster resources) Jörg On Tue, Jun 10, 2014 at 9:03 AM, Pradeep Narayan [pradeepnbhat@gmail.com](mailto:pradeepnbhat@gmail.com) wrote: > Hi - We are designing a system for reporting and are planning to use > Elastic search as a backend. We want to expose reporting in such a way that > users can build custom reports on top of their data without us coming in > their way. One way to do this is to expose Elasticsearch query APIs > through our public endpoints. The other option is to use an abstraction > language which get translated to Elasticsearch queries in the middle tier. > The latter option allows us to control what runs on ES but can become > restrictive in terms of how much we expose the rich query mechanism of ES > using the abstraction layer. I would like to know if there is a known > design pattern to solve this. How have users of Elasticsearch addressed > flexibility vs. control? > > Regards, > Pradeep > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/7b09e135-578d-420a-9dc6-da503e4b3163%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7b09e135-578d-420a-9dc6-da503e4b3163%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/7b09e135-578d-420a-9dc6-da503e4b3163%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/7b09e135-578d-420a-9dc6-da503e4b3163%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHsDC-oXVpsptc%2BZLFXwSsr126QyQuekbCgjT1pzuBkoA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHsDC-oXVpsptc%2BZLFXwSsr126QyQuekbCgjT1pzuBkoA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Zennet\_Wheatcroft](https://avatars.discourse-cdn.com/v4/letter/z/8491ac/32.png) [@Zennet\_Wheatcroft](https://discuss.elastic.co/u/Zennet_Wheatcroft)\ **Post date:** [June 10, 2014, 10:38pm UTC](https://discuss.elastic.co/t/exposing-elastic-search-query-apis-at-a-public-endpoint/18006/3 "2014-06-10T22:38:41Z")
Hi Pradeep, We are in the middle of doing the same thing, designing a system for reporting. And I want to create a middle API layer for the reasons you suggest and other reasons. I would like to exchange notes with you in a private message, if you want. You have to create some middle later, right? You don't want to let users issue request for DELETE [http://yourhost:9200/\_all/](http://yourhost:9200/_all/). Zennet On Tuesday, June 10, 2014 12:03:08 AM UTC-7, Pradeep Narayan wrote: > Hi - We are designing a system for reporting and are planning to use > Elastic search as a backend. We want to expose reporting in such a way that > users can build custom reports on top of their data without us coming in > their way. One way to do this is to expose Elasticsearch query APIs > through our public endpoints. The other option is to use an abstraction > language which get translated to Elasticsearch queries in the middle tier. > The latter option allows us to control what runs on ES but can become > restrictive in terms of how much we expose the rich query mechanism of ES > using the abstraction layer. I would like to know if there is a known > design pattern to solve this. How have users of Elasticsearch addressed > flexibility vs. control? > > Regards, > Pradeep -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/ad6388f1-d1df-40b6-90c8-d9b87bea17cd%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/ad6388f1-d1df-40b6-90c8-d9b87bea17cd%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:23am UTC](https://discuss.elastic.co/t/exposing-elastic-search-query-apis-at-a-public-endpoint/18006/4 "2017-07-06T01:23:29Z")