REST API responses can be too verbose - Neo4j

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion REST API responses can be too verbose
Received-SPF: pass (google.com: domain of neubauer.pe...@gmail.com designates 209.85.213.43 as permitted sender) client-ip=209.85.213.43;
MIME-Version: 1.0
Sender: neubauer.pe...@gmail.com
In-Reply-To: <22941428.979.1336409329277.JavaMail.geo-discussion-forums@vbbfr18>
References: <31548345.235.1336402672342.JavaMail.geo-discussion-forums@vbkk11>
 <CAF59RW66QiJcJkYEzHbjKu+X12S-KOLo5a=Am7n4wn3hEs4...@mail.gmail.com>
 <8200719.196.1336406851482.JavaMail.geo-discussion-forums@vbez20>
 <CAF59RW6WYVrbzFgi-a+Em+amQVhg=xeNS9EJ175v1L60i5d...@mail.gmail.com> <22941428.979.1336409329277.JavaMail.geo-discussion-forums@vbbfr18>
From: Peter Neubauer <peter.neuba...@neotechnology.com>
Date: Mon, 7 May 2012 18:54:22 +0200
Message-ID: <CAF59RW6Qr3hnO5J5gp+Z1cLTWcrrW_pDeFOhFTZuxoWZi__...@mail.gmail.com>
Subject: Re: [Neo4j] REST API responses can be too verbose
To: neo4j@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Brian,
what is the rationale behind your worry? Would you like to access
MySQL via REST Tuple atomic operations rather than SQL? I think this
is a VERY important discussion, for all of us.

Cheers,

/peter neubauer

G: =A0neubauer.peter
S: =A0peter.neubauer
P: =A0+46 704 106975
L:=A0 =A0http://www.linkedin.com/in/neubauer
T: =A0 @peterneubauer

If you can write, you can code - @coderdojomalmo
If you can sketch, you can use a graph database - @neo4j


On Mon, May 7, 2012 at 6:48 PM, brian <blevine...@gmail.com> wrote:
> This makes sense. =A0Although I think there's still a place for a "pure"
> RESTful API that addresses resources atomically. When that's too
> fine-grained or not performant, batching methods over REST can be used.
> =A0When even that's not sufficient either because it's not performant or =
not
> expressive enough, using a query language with mutation support can be us=
ed.
> =A0However, I start getting worried when the only way to use a REST API i=
s to
> tunnel a query language (e.g. Cypher) or a programming language (e.g.
> Groovy) over REST.
>
> -b
>
>
> On Monday, May 7, 2012 12:18:35 PM UTC-4, Peter Neubauer wrote:
>>
>> Right.
>> We have been thinking of a more compact JSON format, as the default
>> one is really geared towards Hypermedia (so everything you get back is
>> actually discoverable and standalone, which makes it verbose).
>> However, it seems that more pragmatic formats are more popular.
>>
>> Having the compact format is one thing, the other is the question if
>> the atomic REST API is the right way to express operations in the DB.
>> We now think that Cypher is a better way to do that. Indexing
>> operations are notably missing from that right now, since there are
>> plans to work on a much better indexing infrastructure in the
>> not-too-far future, so Cypher should wait for that.
>>
>> So, I think using the REST indexing subset (maybe using streaming
>> Batch operations for better performance, see
>>
>> http://docs.neo4j.org/chunked/snapshot/rest-api-batch-ops.html#rest-api-=
execute-multiple-operations-in-batch-streaming)
>> might be the best solution, or maybe Gremlin and server side groovy
>> access to the Java indexing API, see
>>
>> http://docs.neo4j.org/chunked/snapshot/gremlin-plugin.html#rest-api-send=
-an-arbitrary-groovy-script---lucene-sorting
>> .
>>
>> Does that make sense?
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> G: =A0neubauer.peter
>> S: =A0peter.neubauer
>> P: =A0+46 704 106975
>> L:=A0 =A0http://www.linkedin.com/in/neubauer
>> T: =A0 @peterneubauer
>>
>> If you can write, you can code - @coderdojomalmo
>> If you can sketch, you can use a graph database - @neo4j
>>
>>
>> On Mon, May 7, 2012 at 6:07 PM, brian =A0wrote:
>> > Thank you Peter. =A0I was actually referring to the REST response I
>> > receive
>> > when *adding* an index entry as opposed to querying the index. =A0But =
my
>> > post
>> > also had to do with how verbose REST responses are in general. I'd hat=
e
>> > to
>> > think that I have to resort to issuing REST requests using some query
>> > language within the request just to work around the verbosity issue.
>> > =A0And in
>> > my specific case of adding an index entry, I'm wondering whether some =
of
>> > the
>> > information you're returning (e.g. in the Location header) is actually
>> > useful. What can you do with the URL returned in that Location header.
>> >
>> > -b
>> >
>> >
>> > On Monday, May 7, 2012 11:38:34 AM UTC-4, Peter Neubauer wrote:
>> >>
>> >> I think you could instead do a Cypher index lookup and then just retu=
rn
>> >> what you need, like
>> >>
>> >> Start n=3Dnode:persons(name =3D 'test') return id(n)
>> >>
>> >> ?
>> >>
>> >> On May 7, 2012 5:35 PM, "Brian Levine" =A0wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I ran into this while using the REST API to add properties of a node
>> >>> to a
>> >>> full-text index. =A0From the documentation (1.7), you can see that t=
o
>> >>> add a
>> >>> property/value to a node index, one does:
>> >>>
>> >>> POST=A0http://localhost:7474/db/data/index/node/favorites
>> >>>
>> >>> with a JSON payload including the URI of the node, the key and the
>> >>> value.
>> >>> =A0On success, the response code is 201 and a Location header contai=
ning
>> >>> a URL
>> >>> of the form:
>> >>>
>> >>>
>> >>>
>> >>> "http://localhost:7474/db/data/index/node/favorites/some-key/some%20=
value/106"
>> >>>
>> >>> This URL is also included in the "indexed" property in the JSON
>> >>> response
>> >>> which seems unnecessary to me (since it's already included in the
>> >>> Location
>> >>> header).
>> >>>
>> >>> In my case, I'm using a full-text index and the value can be large
>> >>> which
>> >>> could result in a very large (and possible invalid) URL. I'm not sur=
e
>> >>> what
>> >>> the caller would do with this location URL anyway. Can you do a GET =
on
>> >>> it?
>> >>>
>> >>> I think this is a case where the REST API has erred on the side of
>> >>> returning too much information in an effort to support the RESTful
>> >>> best
>> >>> practice of discovery. In fact, I'd vote for an optional "non-verbos=
e"
>> >>> mode
>> >>> in the REST API so that smaller payloads are returned. This is
>> >>> especially
>> >>> important for clients on mobile devices where your user might be
>> >>> paying for
>> >>> all that data.
>> >>>
>> >>> -brian
>> >>>
>> >
>
>
> On Monday, May 7, 2012 12:18:35 PM UTC-4, Peter Neubauer wrote:
>>
>> Right.
>> We have been thinking of a more compact JSON format, as the default
>> one is really geared towards Hypermedia (so everything you get back is
>> actually discoverable and standalone, which makes it verbose).
>> However, it seems that more pragmatic formats are more popular.
>>
>> Having the compact format is one thing, the other is the question if
>> the atomic REST API is the right way to express operations in the DB.
>> We now think that Cypher is a better way to do that. Indexing
>> operations are notably missing from that right now, since there are
>> plans to work on a much better indexing infrastructure in the
>> not-too-far future, so Cypher should wait for that.
>>
>> So, I think using the REST indexing subset (maybe using streaming
>> Batch operations for better performance, see
>>
>> http://docs.neo4j.org/chunked/snapshot/rest-api-batch-ops.html#rest-api-=
execute-multiple-operations-in-batch-streaming)
>> might be the best solution, or maybe Gremlin and server side groovy
>> access to the Java indexing API, see
>>
>> http://docs.neo4j.org/chunked/snapshot/gremlin-plugin.html#rest-api-send=
-an-arbitrary-groovy-script---lucene-sorting
>> .
>>
>> Does that make sense?
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> G: =A0neubauer.peter
>> S: =A0peter.neubauer
>> P: =A0+46 704 106975
>> L:=A0 =A0http://www.linkedin.com/in/neubauer
>> T: =A0 @peterneubauer
>>
>> If you can write, you can code - @coderdojomalmo
>> If you can sketch, you can use a graph database - @neo4j
>>
>>
>> On Mon, May 7, 2012 at 6:07 PM, brian =A0wrote:
>> > Thank you Peter. =A0I was actually referring to the REST response I
>> > receive
>> > when *adding* an index entry as opposed to querying the index. =A0But =
my
>> > post
>> > also had to do with how verbose REST responses are in general. I'd hat=
e
>> > to
>> > think that I have to resort to issuing REST requests using some query
>> > language within the request just to work around the verbosity issue.
>> > =A0And in
>> > my specific case of adding an index entry, I'm wondering whether some =
of
>> > the
>> > information you're returning (e.g. in the Location header) is actually
>> > useful. What can you do with the URL returned in that Location header.
>> >
>> > -b
>> >
>> >
>> > On Monday, May 7, 2012 11:38:34 AM UTC-4, Peter Neubauer wrote:
>> >>
>> >> I think you could instead do a Cypher index lookup and then just retu=
rn
>> >> what you need, like
>> >>
>> >> Start n=3Dnode:persons(name =3D 'test') return id(n)
>> >>
>> >> ?
>> >>
>> >> On May 7, 2012 5:35 PM, "Brian Levine" =A0wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I ran into this while using the REST API to add properties of a node
>> >>> to a
>> >>> full-text index. =A0From the documentation (1.7), you can see that t=
o
>> >>> add a
>> >>> property/value to a node index, one does:
>> >>>
>> >>> POST=A0http://localhost:7474/db/data/index/node/favorites
>> >>>
>> >>> with a JSON payload including the URI of the node, the key and the
>> >>> value.
>> >>> =A0On success, the response code is 201 and a Location header contai=
ning
>> >>> a URL
>> >>> of the form:
>> >>>
>> >>>
>> >>>
>> >>> "http://localhost:7474/db/data/index/node/favorites/some-key/some%20=
value/106"
>> >>>
>> >>> This URL is also included in the "indexed" property in the JSON
>> >>> response
>> >>> which seems unnecessary to me (since it's already included in the
>> >>> Location
>> >>> header).
>> >>>
>> >>> In my case, I'm using a full-text index and the value can be large
>> >>> which
>> >>> could result in a very large (and possible invalid) URL. I'm not sur=
e
>> >>> what
>> >>> the caller would do with this location URL anyway. Can you do a GET =
on
>> >>> it?
>> >>>
>> >>> I think this is a case where the REST API has erred on the side of
>> >>> returning too much information in an effort to support the RESTful
>> >>> best
>> >>> practice of discovery. In fact, I'd vote for an optional "non-verbos=
e"
>> >>> mode
>> >>> in the REST API so that smaller payloads are returned. This is
>> >>> especially
>> >>> important for clients on mobile devices where your user might be
>> >>> paying for
>> >>> all that data.
>> >>>
>> >>> -brian
>> >>>
>> >
>
>
> On Monday, May 7, 2012 12:18:35 PM UTC-4, Peter Neubauer wrote:
>>
>> Right.
>> We have been thinking of a more compact JSON format, as the default
>> one is really geared towards Hypermedia (so everything you get back is
>> actually discoverable and standalone, which makes it verbose).
>> However, it seems that more pragmatic formats are more popular.
>>
>> Having the compact format is one thing, the other is the question if
>> the atomic REST API is the right way to express operations in the DB.
>> We now think that Cypher is a better way to do that. Indexing
>> operations are notably missing from that right now, since there are
>> plans to work on a much better indexing infrastructure in the
>> not-too-far future, so Cypher should wait for that.
>>
>> So, I think using the REST indexing subset (maybe using streaming
>> Batch operations for better performance, see
>>
>> http://docs.neo4j.org/chunked/snapshot/rest-api-batch-ops.html#rest-api-=
execute-multiple-operations-in-batch-streaming)
>> might be the best solution, or maybe Gremlin and server side groovy
>> access to the Java indexing API, see
>>
>> http://docs.neo4j.org/chunked/snapshot/gremlin-plugin.html#rest-api-send=
-an-arbitrary-groovy-script---lucene-sorting
>> .
>>
>> Does that make sense?
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> G: =A0neubauer.peter
>> S: =A0peter.neubauer
>> P: =A0+46 704 106975
>> L:=A0 =A0http://www.linkedin.com/in/neubauer
>> T: =A0 @peterneubauer
>>
>> If you can write, you can code - @coderdojomalmo
>> If you can sketch, you can use a graph database - @neo4j
>>
>>
>> On Mon, May 7, 2012 at 6:07 PM, brian =A0wrote:
>> > Thank you Peter. =A0I was actually referring to the REST response I
>> > receive
>> > when *adding* an index entry as opposed to querying the index. =A0But =
my
>> > post
>> > also had to do with how verbose REST responses are in general. I'd hat=
e
>> > to
>> > think that I have to resort to issuing REST requests using some query
>> > language within the request just to work around the verbosity issue.
>> > =A0And in
>> > my specific case of adding an index entry, I'm wondering whether some =
of
>> > the
>> > information you're returning (e.g. in the Location header) is actually
>> > useful. What can you do with the URL returned in that Location header.
>> >
>> > -b
>> >
>> >
>> > On Monday, May 7, 2012 11:38:34 AM UTC-4, Peter Neubauer wrote:
>> >>
>> >> I think you could instead do a Cypher index lookup and then just retu=
rn
>> >> what you need, like
>> >>
>> >> Start n=3Dnode:persons(name =3D 'test') return id(n)
>> >>
>> >> ?
>> >>
>> >> On May 7, 2012 5:35 PM, "Brian Levine" =A0wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I ran into this while using the REST API to add properties of a node
>> >>> to a
>> >>> full-text index. =A0From the documentation (1.7), you can see that t=
o
>> >>> add a
>> >>> property/value to a node index, one does:
>> >>>
>> >>> POST=A0http://localhost:7474/db/data/index/node/favorites
>> >>>
>> >>> with a JSON payload including the URI of the node, the key and the
>> >>> value.
>> >>> =A0On success, the response code is 201 and a Location header contai=
ning
>> >>> a URL
>> >>> of the form:
>> >>>
>> >>>
>> >>>
>> >>> "http://localhost:7474/db/data/index/node/favorites/some-key/some%20=
value/106"
>> >>>
>> >>> This URL is also included in the "indexed" property in the JSON
>> >>> response
>> >>> which seems unnecessary to me (since it's already included in the
>> >>> Location
>> >>> header).
>> >>>
>> >>> In my case, I'm using a full-text index and the value can be large
>> >>> which
>> >>> could result in a very large (and possible invalid) URL. I'm not sur=
e
>> >>> what
>> >>> the caller would do with this location URL anyway. Can you do a GET =
on
>> >>> it?
>> >>>
>> >>> I think this is a case where the REST API has erred on the side of
>> >>> returning too much information in an effort to support the RESTful
>> >>> best
>> >>> practice of discovery. In fact, I'd vote for an optional "non-verbos=
e"
>> >>> mode
>> >>> in the REST API so that smaller payloads are returned. This is
>> >>> especially
>> >>> important for clients on mobile devices where your user might be
>> >>> paying for
>> >>> all that data.
>> >>>
>> >>> -brian
>> >>>
>> >
>
>
> On Monday, May 7, 2012 12:18:35 PM UTC-4, Peter Neubauer wrote:
>>
>> Right.
>> We have been thinking of a more compact JSON format, as the default
>> one is really geared towards Hypermedia (so everything you get back is
>> actually discoverable and standalone, which makes it verbose).
>> However, it seems that more pragmatic formats are more popular.
>>
>> Having the compact format is one thing, the other is the question if
>> the atomic REST API is the right way to express operations in the DB.
>> We now think that Cypher is a better way to do that. Indexing
>> operations are notably missing from that right now, since there are
>> plans to work on a much better indexing infrastructure in the
>> not-too-far future, so Cypher should wait for that.
>>
>> So, I think using the REST indexing subset (maybe using streaming
>> Batch operations for better performance, see
>>
>> http://docs.neo4j.org/chunked/snapshot/rest-api-batch-ops.html#rest-api-=
execute-multiple-operations-in-batch-streaming)
>> might be the best solution, or maybe Gremlin and server side groovy
>> access to the Java indexing API, see
>>
>> http://docs.neo4j.org/chunked/snapshot/gremlin-plugin.html#rest-api-send=
-an-arbitrary-groovy-script---lucene-sorting
>> .
>>
>> Does that make sense?
>>
>> Cheers,
>>
>> /peter neubauer
>>
>> G: =A0neubauer.peter
>> S: =A0peter.neubauer
>> P: =A0+46 704 106975
>> L:=A0 =A0http://www.linkedin.com/in/neubauer
>> T: =A0 @peterneubauer
>>
>> If you can write, you can code - @coderdojomalmo
>> If you can sketch, you can use a graph database - @neo4j
>>
>>
>> On Mon, May 7, 2012 at 6:07 PM, brian wrote:
>> > Thank you Peter. =A0I was actually referring to the REST response I
>> > receive
>> > when *adding* an index entry as opposed to querying the index. =A0But =
my
>> > post
>> > also had to do with how verbose REST responses are in general. I'd hat=
e
>> > to
>> > think that I have to resort to issuing REST requests using some query
>> > language within the request just to work around the verbosity issue.
>> > =A0And in
>> > my specific case of adding an index entry, I'm wondering whether some =
of
>> > the
>> > information you're returning (e.g. in the Location header) is actually
>> > useful. What can you do with the URL returned in that Location header.
>> >
>> > -b
>> >
>> >
>> > On Monday, May 7, 2012 11:38:34 AM UTC-4, Peter Neubauer wrote:
>> >>
>> >> I think you could instead do a Cypher index lookup and then just retu=
rn
>> >> what you need, like
>> >>
>> >> Start n=3Dnode:persons(name =3D 'test') return id(n)
>> >>
>> >> ?
>> >>
>> >> On May 7, 2012 5:35 PM, "Brian Levine" =A0wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I ran into this while using the REST API to add properties of a node
>> >>> to a
>> >>> full-text index. =A0From the documentation (1.7), you can see that t=
o
>> >>> add a
>> >>> property/value to a node index, one does:
>> >>>
>> >>> POST=A0http://localhost:7474/db/data/index/node/favorites
>> >>>
>> >>> with a JSON payload including the URI of the node, the key and the
>> >>> value.
>> >>> =A0On success, the response code is 201 and a Location header contai=
ning
>> >>> a URL
>> >>> of the form:
>> >>>
>> >>>
>> >>>
>> >>> "http://localhost:7474/db/data/index/node/favorites/some-key/some%20=
value/106"
>> >>>
>> >>> This URL is also included in the "indexed" property in the JSON
>> >>> response
>> >>> which seems unnecessary to me (since it's already included in the
>> >>> Location
>> >>> header).
>> >>>
>> >>> In my case, I'm using a full-text index and the value can be large
>> >>> which
>> >>> could result in a very large (and possible invalid) URL. I'm not sur=
e
>> >>> what
>> >>> the caller would do with this location URL anyway. Can you do a GET =
on
>> >>> it?
>> >>>
>> >>> I think this is a case where the REST API has erred on the side of
>> >>> returning too much information in an effort to support the RESTful
>> >>> best
>> >>> practice of discovery. In fact, I'd vote for an optional "non-verbos=
e"
>> >>> mode
>> >>> in the REST API so that smaller payloads are returned. This is
>> >>> especially
>> >>> important for clients on mobile devices where your user might be
>> >>> paying for
>> >>> all that data.
>> >>>
>> >>> -brian
>> >>>
>> >
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
