Apache Ignite Developers - Legacy Mail Archive

Ignite REST API is not actually RESTful

Classic

List

Threaded

8 messages Options

Pavel Tupitsyn

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.

Alexey Kuznetsov-2

Re: Ignite REST API is not actually RESTful

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 <[hidden email]>
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

Anton Vinogradov

Re: Ignite REST API is not actually RESTful

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 <[hidden email]>
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 <[hidden email]>
> 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

Re: Ignite REST API is not actually RESTful

In reply to this post by Alexey Kuznetsov-2

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 <[hidden email]>
wrote:

--
Sergey Kozlov
GridGain Systems
www.gridgain.com

Pavel Tupitsyn-3

Re: Ignite REST API is not actually RESTful

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 <[hidden email]> 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 <[hidden email]
> >
> 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 <[hidden email]>
> > 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-2

Re: Ignite REST API is not actually RESTful

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 <[hidden email]>
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 <[hidden email]>
> 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 <
> [hidden email]
> > >
> > 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 <[hidden email]>
> > > 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

Anton Vinogradov

Re: Ignite REST API is not actually RESTful

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> > [hidden email]
> > > >
> > > 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 <
> [hidden email]>
> > > > 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
>

Vladimir Ozerov

Re: Ignite REST API is not actually RESTful

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 <[hidden email]>
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 <[hidden email]
> >
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > >
> > > > 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 <
> > [hidden email]>
> > > > > 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
> >
>