Pavel, >> What is the use case? As far as I know it could be used for quick testing. But I agree that it is not mandatory. Testing could be done with appropriate tools.
>>> 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). In this case we will force users to implement complex solutions. IMHO in some cases we could have state. On Mon, Jun 20, 2016 at 9:37 PM, Pavel Tupitsyn <ptupit...@gridgain.com> wrote: > 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 > > > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
