Be stateless == be intrinsically limited. No transactions, no efficient queries, etc.. We have serious interest to both HTTP protocol itself and to Node.JS integration which is based on it. If we are concerned about "REST" word, then lets rename it to "not-exactly-REST" :-)
Vladimir. On Mon, Jun 20, 2016 at 5:55 PM, Anton Vinogradov <avinogra...@gridgain.com> wrote: > Alexey, > In this case we will make Not REST again. > > Here is good article about idempotency: > http://www.restapitutorial.com/lessons/idempotency.html > > On Mon, Jun 20, 2016 at 5:46 PM, Alexey Kuznetsov <akuznet...@gridgain.com > > > wrote: > > > 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 > > >
