feature(client): support go client for hugegraph

[izliang]

Purpose of the PR

subtask of #512

Main Changes

Add Hugegraph-client for golang
Support REST API By This feature

Verifying these changes

• Trivial rework / code cleanup without any test coverage. (No Need)
• Already covered by existing tests, such as (make test).
• Need tests and can be verified as follows:
  • xxx

Does this PR potentially affect the following parts?

• Nope
• Dependencies (add/update license info)
• Modify configurations
• The public API
• Other affects (typed here)

Documentation Status

• Doc - TODO
• Doc - Done
• Doc - No Need

[codecov]

Codecov Report

Attention: 10 lines in your changes are missing coverage. Please review.

Comparison is base (b066b80) 62.49% compared to head (22b9c3d) 62.46%.
Report is 6 commits behind head on master.

Files	Patch %	Lines
...n/java/org/apache/hugegraph/driver/HugeClient.java	33.33%	2 Missing ⚠️
...egraph/loader/direct/loader/HBaseDirectLoader.java	0.00%	2 Missing ⚠️
.../apache/hugegraph/loader/executor/LoadOptions.java	33.33%	2 Missing ⚠️
...java/org/apache/hugegraph/api/graph/VertexAPI.java	80.00%	1 Missing ⚠️
...ava/org/apache/hugegraph/api/graphs/GraphsAPI.java	66.66%	1 Missing ⚠️
...n/java/org/apache/hugegraph/client/RestClient.java	80.00%	0 Missing and 1 partial ⚠️
...rg/apache/hugegraph/exception/ServerException.java	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #514      +/-   ##
============================================
- Coverage     62.49%   62.46%   -0.04%     
+ Complexity     1903     1902       -1     
============================================
  Files           262      262              
  Lines          9541     9533       -8     
  Branches        886      886              
============================================
- Hits           5963     5955       -8     
  Misses         3190     3190              
  Partials        388      388              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[javeme]

Is it still in progress?

[izliang]

In process

[javeme]

seems don't need to wrap line

[imbajin]

seems don't need to wrap line

Too long to read & break the auto-format rule, if it doesn't affect the pom attribute of the function, it is better to wrap line by 100 characters rather than put them in a LONG line

[hankwenyx]

Go follows a convention where source files are all lower case with underscore separating multiple words. why not use api_response.go？other source files have the same question.

[izliang]

Normally, in Go language, underline is used as the file separator. Here, because the API is a tree structure, English commas are used to distinguish between trees, and then underline is used for segmentation. For example: api.veretx.create.go and api.vertex.get_ by_id.go . The use of English commas and underscores is more conducive to presentation and layering.

[z7658329]

Normally, in Go language, underline is used as the file separator. Here, because the API is a tree structure, English commas are used to distinguish between trees, and then underline is used for segmentation. For example: api.veretx.create.go and api.vertex.get_ by_id.go . The use of English commas and underscores is more conducive to presentation and layering.

@izliang @hankwenyx
should we follow the example of other graph communities? like nebula community go's sdk, seems does not use this naming style:

how about the following style:

• main.go
• api/
  • user/
    • user.go
  • product/
    • product.go
  • order/
    • order.go

[izliang]

At present, it is necessary to explore implementation solutions for the design of file directories and responsibilities for various APIs. There are currently several design options available:

1. In the form of one API per file, this solution references the design of ElasticSerach. Code library address
2. Using all one file and API formats, this solution references the design of Prometheus. Code library address
3. By aggregating some APIs into a single file, this solution refers to the design of Influxdb. Code library address

@zyxxoo @hankwenyx @javeme @coderzc @Radeity could choose one

[zyxxoo]

At present, it is necessary to explore implementation solutions for the design of file directories and responsibilities for various APIs. There are currently several design options available:

1. In the form of one API per file, this solution references the design of ElasticSerach. Code library address
2. Using all one file and API formats, this solution references the design of Prometheus. Code library address
3. By aggregating some APIs into a single file, this solution refers to the design of Influxdb. Code library address

@zyxxoo @hankwenyx @javeme @coderzc @Radeity could choose one

Good idea, Maybe I choose 3 =.=, this style like with java style

[coderzc]

At present, it is necessary to explore implementation solutions for the design of file directories and responsibilities for various APIs. There are currently several design options available:

1. In the form of one API per file, this solution references the design of ElasticSerach. Code library address
2. Using all one file and API formats, this solution references the design of Prometheus. Code library address
3. By aggregating some APIs into a single file, this solution refers to the design of Influxdb. Code library address

@zyxxoo @hankwenyx @javeme @coderzc @Radeity could choose one

I also think 3nd is better.

[javeme]

At present, it is necessary to explore implementation solutions for the design of file directories and responsibilities for various APIs. There are currently several design options available:

1. In the form of one API per file, this solution references the design of ElasticSerach. Code library address
2. Using all one file and API formats, this solution references the design of Prometheus. Code library address
3. By aggregating some APIs into a single file, this solution refers to the design of Influxdb. Code library address

@zyxxoo @hankwenyx @javeme @coderzc @Radeity could choose one

I am not familiar with the Go language, you can refer to zyxxoo and coderzc's suggestions.

[imbajin]

need handle some CI problems:
https://github.com/apache/incubator-hugegraph-toolchain/actions/runs/6951881673/job/18916919111?pr=514

[qwtsc]

I think you can try something like this openapi generator. Other parts LGTM.