[suggestion] more RESTful API path

[iolo]

this is NOT a bug. just a suggestion.

IMHO, current REST API path is not so RESTful. mostly, HTTP method is duplicated in path again. :S

for example(for compatibility, I prepend `api version* in path),

• POST .../graphs/createService into POST .../apis/v2/services
• GET .../graphs/getService/KakaoFavorites into GET .../apis/v2/services/KakaoFavorites
• POST .../graphs/createLabel into POST .../apis/v2/labels
• GET .../graphs/getLabel/friends into GET .../apis/v2/labels/friends
• POST .../graphs/edges/insert into POST .../apis/v2/edges

I know, query APIs are not easy as above. ;) Those are complex and special cases.

There are too many params to use these:

• POST '.../graphs/getEdgesinto GET.../apis/v1/edges`
• POST /graphs/getVertices into GET .../apis/v1/vertices

for query APIs, we need a new approach(similar to prepared statement in RDBMS):

for example, the query APIs could be provided with two steps:

• POST .../apis/v2/queries - create getEdges/checkEdges/getVertices query and return queryId(generated or specified). like a prepared statement.
• and GET .../apis/v2/queries/queryId -- execute prepared statement created by above api.

with this approach, we can provide more fine-graned apis:

• GET .../apis/v2/queries/queryId/steps -- get all steps of a query
• POST .../apis/v2/quries/queryId/steps -- add new step
• DELETE .../apis/v2/quries/queryId/steps/stepIndex -- delete existing step
• et all...

I guess, we need more consideration for easy and clear apis.

[HyunsungJo]

@iolo, Thank you very much for your interest and helpful ideas. This is not the first time someone pointed out that the S2Graph API is not RESTful. So we are fully aware of the issue and will try to enhance the usability of the API taking your suggestion under consideration. Meanwhile, let me go ahead and close this issue since this is expected to be a long-term process.