Alexey, > be able to run all command from browser address line What is the use case? Non-developers do not need that. Developers have better tools than a browser to test an API. GET requests must never modify data, this is very important. People and software assume GET to be safe.
> large SQL query that could be fetched page by page REST is stateless. This should be handled by the user (with LIMIT/OFFSET in SQL). Pavel. On Mon, Jun 20, 2016 at 5:20 PM, Sergey Kozlov <skoz...@gridgain.com> wrote: > We also can consider to keep the compatibility and move new API either to > new http port or use new url (e.g. http://localhost:8080/api/rest instead > of http://localhost:8080/ignite) > > On Mon, Jun 20, 2016 at 5:15 PM, Alexey Kuznetsov <akuznet...@gridgain.com > > > wrote: > > > Pavel, > > > > Current API was developed long time ago and was not actively developed. > > It may looks inconsistent for some use cases. > > May be it is a good idea to develop new API and deprecate current. > > > > From my experience we should take care: > > 1) "null" cache names > > 2) some commands could have state, for example large SQL query that could > > be fetched page by page > > 3) It will be "nice to have" to be able to run all command from browser > > address line. > > > > > > On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn <ptupit...@apache.org> > > wrote: > > > > > Igniters, > > > > > > There are two serious issues with current Ignite REST API: > > > > > > 1) It does not care about HTTP verbs (GET/POST/etc). > > > GET must never modify anything, for example (because GET requests can > be > > > cached, duplicated, etc). > > > > > > 2) Proper resource paths are not used > > > For example, to get a cache value, instead of > > > GET /ignite?cmd=get&key=myKey&cacheName=partionedCache > > > it should be > > > GET /ignite/caches/partitionedCache/keys/myKey/ > > > > > > Modify cache key: > > > PUT /ignite/caches/partitionedCache/keys/myKey/ > > > DELETE /ignite/caches/partitionedCache/keys/myKey/ > > > > > > > > > I think we should deprecate current API and provide a new one that > > follows > > > the guidelines. > > > A good writeup on a proper REST API design can be found there: > > > https://zalando.github.io/restful-api-guidelines/ > > > > > > > > > Thoughts, comments? > > > > > > Pavel. > > > > > > > > > > > -- > > Alexey Kuznetsov > > GridGain Systems > > www.gridgain.com > > > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com >
