Hi,
on the write consistency parameter, it's been removed starting from Elasticsearch 5.0 in favour of the new wait_for_active_shards parameter. See https://github.com/elastic/elasticsearch/pull/19454 to know more. Anyways, consistency did not have anything to do with the operation being successful or not, it was just a check that enough shard copies were around, performed before the write operation was performed.
On knowing whether the index operation was successful or not, if there were failures etc. everything that's exposed via REST (see docs here) is also exposed to the high-level REST client: either an exception is thrown, meaning that the index operation failed completely, or you can find in the response the _shards section that says how many total shards the operation was supposed to be executed on, how many of them failed and how many of them performed the operation successfully. You can check in the high-level client docs how to retrieve such section using the high-level client.
On the search API, we currently only throw exceptions only in case of total failure, meaning all shards failed. This is not specific to the high-level client though, that's how Elasticsearch works at REST. When you do get a SearchResponse back , again you need to check whether you got partial results or results coming from all the shards, in the same way as when indexing, looking at the _shards header. Check out the docs for the search response here to find out how to retrieve such info using the high-level REST client.
Cheers
Luca