Hi, And thanks for the answers. So my understanding is at least correct that I did not oversee a feature of the rest endpoints. So probably we will stick with the admin/luke endpoint to achieve our goal.
Since you have been telling me a lot about the xy problem, I will of course give you some more information regarding the X. In the application we integrate the search based on solr. We don't know exactly all fields that will be indexed they can change dynamically. So our idea was to build up a general search service that will connect to the solr core and build the available search options dynamically. If that service encounters a field that is of type tint it can offer a range search to the user. With that approach it would require no change of the application if a new field is added. Hope that makes it a bit clearer Regards Constantin > Am 04.12.2014 um 18:12 schrieb Chris Hostetter <hossman_luc...@fucit.org>: > > > : Subject: REST API Alternative to admin/luke > > this smells like an XY problem ... if /admin/luke gives you the data you > want, why not use /admin/luke ? ... what is it about /admin/luke that > prevents you from solving your problem? what is your ultimate goal? > > : If I use the admin/luke URL all those dynamic fields are listed with their > actual name. > ... > : dynamicFields. I was expecting a similar result like the one through the > : admin/luke URL which would return all the hard coded fields and all the > : ones dynamically being generated. > > https://people.apache.org/~hossman/#xyproblem > XY Problem > > Your question appears to be an "XY Problem" ... that is: you are dealing > with "X", you are assuming "Y" will help you, and you are asking about "Y" > without giving more details about the "X" so that we can understand the > full issue. Perhaps the best solution doesn't involve "Y" at all? > See Also: http://www.perlmonks.org/index.pl?node_id=542341 > > > > -Hoss > http://www.lucidworks.com/
