Documentation is a huge issue

Is your feature request related to a problem? Please describe. Trying to use an API client for an expansive toolset like Elasticsearch without in depth documentation is highly painful.

Describe the solution you’d like With the understanding that there’s almost no documentation of the individual methods and features for the new client, it should be made clear that a lot of the documentation from the NEST days is still applicable. Better yet, reuse the NEST documentation where applicable, update the method names that have changed but are functionally equivalent, and slap an 8.x label on it.

Describe alternatives you’ve considered There aren’t a lot of alternatives to missing documentation other than trial and error. And that is an oh so tedious process.

[sethmlarson]

@b93rn Also wanted to note that I read @svenhartmann’s comment to mean adapting the REST API documentation JSON/parameters into .NET code, not using raw JSON directly. @svenhartmann you can confirm if this is what you meant.

The new .NET client very closely mirrors the actual Elasticsearch API, so this process should be easier compared to trying to do the same for past clients. Hope this helps!

[technige]

Hi all

We genuinely do understand and appreciate that the situation with documentation is far from ideal. And while it is true that this is on our roadmap, I can also see how merely saying that does not help in any immediate way.

It is absolutely the case that we value our users in the .NET community, just as we do those in other language communities. It is however also true that we don’t have unlimited time and people available, and that we continually have to make choices about where best to direct our efforts.

So in order to help us prioritise, can I ask we refocus this thread on identifying the most critical items for which better documentation is required. This, from @jacob-winkler is a great example:

Fluent syntax documentation for queries that exist in 8.x and an exhaustive list of the queries (referenced using their API names in NEST) that don’t exist. Those two things would go a long way as people try and transition from NEST to the 8.x client.

Thanks