You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Pavel Tupitsyn <pt...@apache.org> on 2016/06/20 13:59:10 UTC
Ignite REST API is not actually RESTful
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.
Re: Ignite REST API is not actually RESTful
Posted by Anton Vinogradov <av...@gridgain.com>.
Pavel,
Looks good, but:
According to Swagger demo <http://petstore.swagger.io/#/store> need to use
singular (caches->cache).
And I'm also not sure we need ignite preffix.
On Mon, Jun 20, 2016 at 5:15 PM, Alexey Kuznetsov <ak...@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 <pt...@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
>
Re: Ignite REST API is not actually RESTful
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <av...@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 <akuznetsov@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 <pt...@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 <sk...@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 <
> > > akuznetsov@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 <
> > ptupitsyn@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
> >
>
Re: Ignite REST API is not actually RESTful
Posted by Anton Vinogradov <av...@gridgain.com>.
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 <ak...@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 <pt...@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 <sk...@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 <
> > akuznetsov@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 <
> ptupitsyn@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
>
Re: Ignite REST API is not actually RESTful
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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 <pt...@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 <sk...@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 <
> akuznetsov@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 <pt...@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
Re: Ignite REST API is not actually RESTful
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
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 <sk...@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 <akuznetsov@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 <pt...@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
>
Re: Ignite REST API is not actually RESTful
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <ak...@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 <pt...@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
Re: Ignite REST API is not actually RESTful
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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 <pt...@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