# OpenSearch Client Java & Python APIs

**URL:** <https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639>\
**Category:** OpenDistro\
**Created:** [April 16, 2021, 12:17am UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639 "2021-04-16T00:17:00Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![asfoorial](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@asfoorial](https://forum.opensearch.org/u/asfoorial)\
**Post date:** [April 16, 2021, 12:17am UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/1 "2021-04-16T00:17:01Z")

</div>

Good day everyone,

Any plan for providing/supporting Elasticsearch Java Highlevel REST APIs and Python APIs?

Will currently writtern code that uses these APIs break now that elasticsearch namespaces have changed to reflect OpenSearch?

Will there be such APIs for OpenSearch maintained in repositories such as Maven Central and PyPI?

Regards,  
Hasan

---

<div class="post-metadata">

**Author:** ![aparo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/aparo/32/224_2.png) [@aparo](https://forum.opensearch.org/u/aparo)\
**Post date:** [April 16, 2021, 8:26am UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/2 "2021-04-16T08:26:27Z")

</div>

@asfoorial I’m working on clients code generator in my spare time.  
I started here the fork of Elasticsearch code generator [GitHub - aparo/opensearch-client-generator: OpenDistro Client code generator to be used with Elasticsearch](https://github.com/aparo/opensearch-client-generator) and now I’m working to providing OpenAPI.  
My task list is the following:

- openAPI descriptor
- Python (typed) client
- Java/Scala client  
My idea is also to provide scripts (python or similar) to automatically migrate the code from Elasticsearch to OpenSearch.

---

<div class="post-metadata">

**Author:** ![asfoorial](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@asfoorial](https://forum.opensearch.org/u/asfoorial)\
**Post date:** [April 16, 2021, 10:05pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/3 "2021-04-16T22:05:02Z")

</div>

@aparo This is good news. However, does it maintain the same Java/Python APIs and signatures? In other words, if we have existing code that uses current elasticsearch Java/Python APIs would it continue to work if we use these new OpenSearch Java/Python clients?

Thanks,  
Hasan

---

<div class="post-metadata">

**Author:** ![aparo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/aparo/32/224_2.png) [@aparo](https://forum.opensearch.org/u/aparo)\
**Post date:** [April 17, 2021, 4:09pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/4 "2021-04-17T16:09:11Z")

</div>

@asfoorial I will try to keep as it the API, but the python ones are missing types and in some case also parameters.

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [May 29, 2021, 7:59pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/5 "2021-05-29T19:59:16Z")

</div>

@aparo I tried to generate python client from OpenSearch repo. It was successful. I believe types can be added but typing depends what versions the package should support. I would recommend putting up compatibility requirements. IMO, I would drop python 2 support completely. And requires 3.7+ since aiohttp support 3.7+.

The documentation still links to [elastic.co](http://elastic.co). If kept unchanged, I believe that will be difficult to align client users when OpenSearch is released.

---

<div class="post-metadata">

**Author:** ![ralph](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/ralph/32/1194_2.png) [@ralph](https://forum.opensearch.org/u/ralph)\
**Post date:** [May 31, 2021, 7:37am UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/6 "2021-05-31T07:37:23Z")

</div>

> [@erickg](#):
>
> I would drop python 2 support completely

python 2 is dead since last year: [PEP 373 – Python 2.7 Release Schedule | peps.python.org](https://www.python.org/dev/peps/pep-0373/#id2) (we’ll, it’s been dead for much longer, really, but last year marked the official EOL for it)

---

<div class="post-metadata">

**Author:** ![searchymcsearchface](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/searchymcsearchface/32/868_2.png) [@searchymcsearchface](https://forum.opensearch.org/u/searchymcsearchface)\
**Post date:** [May 31, 2021, 2:01pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/7 "2021-05-31T14:01:51Z")

</div>

Can I just say how happy I am that the Python 2/3 thing can be history now?

---

<div class="post-metadata">

**Author:** ![asfoorial](https://avatars.discourse-cdn.com/v4/letter/a/3da27b/32.png) [@asfoorial](https://forum.opensearch.org/u/asfoorial)\
**Post date:** [May 31, 2021, 3:34pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/8 "2021-05-31T15:34:39Z")

</div>

@erickg

Excellent.

Could you please share the code to the generated python API?

Thanks

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [May 31, 2021, 7:13pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/9 "2021-05-31T19:13:07Z")

</div>

@ralph elasticsearch-py still declares Python 2 support as long as 3.4, 3.5, 3.6 from its manifest.

@searchymcsearchface Yep, me too.

@asfoorial Code from elastichsearch-py. I changed `utils/generate-api.py` to get the client code.

> **[GitHub - erickguan/opensearch-py](https://github.com/erickguan/opensearch-py)**
>
> Contribute to erickguan/opensearch-py development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![searchymcsearchface](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/searchymcsearchface/32/868_2.png) [@searchymcsearchface](https://forum.opensearch.org/u/searchymcsearchface)\
**Post date:** [May 31, 2021, 7:39pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/10 "2021-05-31T19:39:24Z")

</div>

Niiiice. Looks like a lot of manual work still needs to be done, but it’s a start.

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [June 1, 2021, 5:30pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/11 "2021-06-01T17:30:53Z")

</div>

Before discussion work, I need some help with license. The README.md stated `Copyright 2021 Elasticsearch B.V. Licensed under the Apache License, Version 2.0.` LICENSE file says Apache License. This is confusing to me.

---

<div class="post-metadata">

**Author:** ![searchymcsearchface](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/searchymcsearchface/32/868_2.png) [@searchymcsearchface](https://forum.opensearch.org/u/searchymcsearchface)\
**Post date:** [June 1, 2021, 6:05pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/12 "2021-06-01T18:05:12Z")

</div>

Let me try and find someone to help you!

---

<div class="post-metadata">

**Author:** ![spotfoss](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/spotfoss/32/1371_2.png) [@spotfoss](https://forum.opensearch.org/u/spotfoss)\
**Post date:** [June 1, 2021, 6:18pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/13 "2021-06-01T18:18:12Z")

</div>

Disclaimer: This is not legal advice, I am not a lawyer. I have worked in the open source legal space for 15+ years and worked closely with Red Hat Legal in my previous job.

@erickg, what you see in the README.md is what I would expect to see when you fork another project. They are attributing the copyright holder on the original work, and documenting the license that the work is under.

As you add/modify code to your fork, their copyright statement (and license for their copyrighted changes) still apply, so you need to be sure to retain that attribution (in README.md and wherever it appears in the code files, probably in the comment header). What you can do is append your own copyright statement, like this:

```auto
Copyright 2021 Elasticsearch B.V. 
Copyright 2021 ErickG

Licensed under the Apache License, Version 2.0

```

You can definitely do this in README.md without issue, and you can make this change to any source files you modify. If you create entirely new files (that do not copy content from existing files), you do not need to include the Elasticsearch copyright attribution statement.

I am assuming, for simplicity, that your fork intends to keep the Apache License, Version 2.0, that you inherited from the upstream fork. It is possible for your changes to be under a different license, but it complicates things (including my answer) quite a bit, so my advice to you would be to keep your fork Apache 2.0.

If you have additional Copyright or License questions, please feel free to ask me, and I will do my best to help you.

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [June 2, 2021, 6:05am UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/14 "2021-06-02T06:05:57Z")

</div>

Thanks, that’s helpful. Of course, I would love to have Apache License.

I have a question about source repo elasticsearch-py’s license. It says

> Copyright 2021 Elasticsearch B.V. Licensed under the Apache License, Version 2.0.

This doesn’t align with APL declaration in [elasticsearch-py/LICENSE at master · elastic/elasticsearch-py (github.com)](https://github.com/elastic/elasticsearch-py/blob/master/LICENSE). Does that mean the code is not APL anymore?

---

<div class="post-metadata">

**Author:** ![searchymcsearchface](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/searchymcsearchface/32/868_2.png) [@searchymcsearchface](https://forum.opensearch.org/u/searchymcsearchface)\
**Post date:** [June 3, 2021, 2:20pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/15 "2021-06-03T14:20:16Z")

</div>

I’m not sure I follow 100% - copyright and license are two separate things. The repo you linked looks like Apache to me.

@spotfoss Thoughts?

---

<div class="post-metadata">

**Author:** ![spotfoss](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/spotfoss/32/1371_2.png) [@spotfoss](https://forum.opensearch.org/u/spotfoss)\
**Post date:** [June 3, 2021, 2:47pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/16 "2021-06-03T14:47:02Z")

</div>

The file that you linked to is a copy of the Apache License 2.0. I am also unsure where your confusion is coming from, as this matches the statement in README.md.

---

<div class="post-metadata">

**Author:** ![aparo](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/aparo/32/224_2.png) [@aparo](https://forum.opensearch.org/u/aparo)\
**Post date:** [June 3, 2021, 4:19pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/17 "2021-06-03T16:19:19Z")

</div>

IMHO, the actual python API sucks because are very 2.x legacy designed.  
They don’t follow the actual approach of using Python Typed for methods and objects.  
It’s ok to maintain for old created code, but for new one it should better to move a more python modern approach.  
The same if for Jaa API that the High-Level are poor of entity model design.

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [June 3, 2021, 5:18pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/18 "2021-06-03T17:18:56Z")

</div>

> [@searchymcsearchface](#):
>
> copyright and license are two separate things

Thanks. It makes sense to me now. Then the library can be licensed as Apache License 2.0 with updated copyright holder when it moves on.

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [June 3, 2021, 5:21pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/19 "2021-06-03T17:21:08Z")

</div>

I’d be more than happy to be able to use more python 3.6 features and onwards if possible. To start, I would aim for being able to make API requests to OpenSearch 1.0 without issues.

---

<div class="post-metadata">

**Author:** ![erickg](https://avatars.discourse-cdn.com/v4/letter/e/d78d45/32.png) [@erickg](https://forum.opensearch.org/u/erickg)\
**Post date:** [June 10, 2021, 10:33pm UTC](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639/20 "2021-06-10T22:33:00Z")

</div>

I spent some time looking at python client codebase. There are different hacks to make it work as of today.  
Since elasticsearch-py 7.\* should be able to work with the 1.0. I think it doesn’t matter for me to break compatibility between two client projects. I aim to build the client to talk to OpenSearch 1.x and drops Elasticsearch compatibility when not possible. Correct me if I misunderstood.

I see some areas to improve:

- Use AST to generate functions instead of using templates.
- See if I can composite API classes after the above point.
- Then the package can go for native typing hints.
  - Start support py 3.6 at least.

- Change API function signature to requests style. Basically, drop `query_params` support which extracts kwargs to params. That confused the most why the client works differently comparing to HTTP requests in Kibana console.
  - Then I don’t need to rename type to doc\_type for URL query parameters.

- Drop XPack API
- Annotate network modules
- A lot of renaming in comments and documentations
- Type hints.
- Changes with OpenSearch
  - Bulk ingestion errors are very difficult to know
  - lz4 compression (this needs clusters support)
  - Probably better to have a pipeline with OpenSearch sooner than later. There are tests that are done together with Jenkins pipeline for elasticsearch-py that requires a cluster.

What do you think it’s important for you? Any other thoughts?

[Next page](https://forum.opensearch.org/t/opensearch-client-java-python-apis/5639.md?page=2)
