I ran into this while using the REST API to add properties of a node to a full-text index. From the documentation (1.7), you can see that to add a property/value to a node index, one does:
with a JSON payload including the URI of the node, the key and the value. On success, the response code is 201 and a Location header containing a URL of the form:
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 sure 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-verbose" 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.
> I ran into this while using the REST API to add properties of a node to a
> full-text index. From the documentation (1.7), you can see that to add a
> property/value to a node index, one does:
> with a JSON payload including the URI of the node, the key and the value.
> On success, the response code is 201 and a Location header containing a
> URL of the form:
> 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 sure 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-verbose" 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.
Thank you Peter. I was actually referring to the REST response I receive when *adding* an index entry as opposed to querying the index. But my post also had to do with how verbose REST responses are in general. I'd hate 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. And 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.
> ? > On May 7, 2012 5:35 PM, "Brian Levine" wrote:
>> Hello,
>> I ran into this while using the REST API to add properties of a node to a >> full-text index. From the documentation (1.7), you can see that to add a >> property/value to a node index, one does:
>> with a JSON payload including the URI of the node, the key and the value. >> On success, the response code is 201 and a Location header containing a >> URL of the form:
>> 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 sure 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-verbose" 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.
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.
On Mon, May 7, 2012 at 6:07 PM, brian <blevine...@gmail.com> wrote:
> Thank you Peter. I was actually referring to the REST response I receive
> when *adding* an index entry as opposed to querying the index. But my post
> also had to do with how verbose REST responses are in general. I'd hate 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. And 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 return
>> what you need, like
>>> I ran into this while using the REST API to add properties of a node to a
>>> full-text index. From the documentation (1.7), you can see that to add a
>>> property/value to a node index, one does:
>>> with a JSON payload including the URI of the node, the key and the value.
>>> On success, the response code is 201 and a Location header containing a URL
>>> of the form:
>>> 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 sure 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-verbose" 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.
This makes sense. Although 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. When even that's not sufficient either because it's not performant or not expressive enough, using a query language with mutation support can be used. However, I start getting worried when the *only *way to use a REST API is to tunnel a query language (e.g. Cypher) or a programming language (e.g. Groovy) over REST.
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
> 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. I was actually referring to the REST response I > receive > > when *adding* an index entry as opposed to querying the index. But my > post > > also had to do with how verbose REST responses are in general. I'd hate > 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. > And 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 return > >> what you need, like
> >> On May 7, 2012 5:35 PM, "Brian Levine" wrote:
> >>> Hello,
> >>> I ran into this while using the REST API to add properties of a node > to a > >>> full-text index. From the documentation (1.7), you can see that to > add a > >>> property/value to a node index, one does:
> >>> with a JSON payload including the URI of the node, the key and the > value. > >>> On success, the response code is 201 and a Location header containing > a URL > >>> of the form:
> >>> 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 sure > 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-verbose" > 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
> 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. I was actually referring to the REST response I > receive > > when *adding* an index entry as opposed to querying the index. But my > post > > also had to do with how verbose REST responses are in general. I'd hate > 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. > And 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 return > >> what you need, like
> >> On May 7, 2012 5:35 PM, "Brian Levine" wrote:
> >>> Hello,
> >>> I ran into this while using the REST API to add properties of a node > to a > >>> full-text index. From the documentation (1.7), you can see that to > add a > >>> property/value to a node index, one does:
> >>> with a JSON payload including the URI of the node, the key and the > value. > >>> On success, the response code is 201 and a Location header containing > a URL > >>> of the form:
> >>> 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 sure > 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-verbose" > 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
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.
On Mon, May 7, 2012 at 6:48 PM, brian <blevine...@gmail.com> wrote:
> This makes sense. Although 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.
> When even that's not sufficient either because it's not performant or not
> expressive enough, using a query language with mutation support can be used.
> However, I start getting worried when the only way to use a REST API is 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
>> 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. I was actually referring to the REST response I
>> > receive
>> > when *adding* an index entry as opposed to querying the index. But my
>> > post
>> > also had to do with how verbose REST responses are in general. I'd hate
>> > 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.
>> > And 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 return
>> >> what you need, like
>> >> On May 7, 2012 5:35 PM, "Brian Levine" wrote:
>> >>> Hello,
>> >>> I ran into this while using the REST API to add properties of a node
>> >>> to a
>> >>> full-text index. From the documentation (1.7), you can see that to
>> >>> add a
>> >>> property/value to a node index, one does:
>> >>> with a JSON payload including the URI of the node, the key and the
>> >>> value.
>> >>> On success, the response code is 201 and a Location header containing
>> >>> a URL
>> >>> of the form:
>> >>> 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 sure
>> >>> 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-verbose"
>> >>> 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
>> 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. I was actually referring to the REST response I
>> > receive
>> > when *adding* an index entry as opposed to querying the index. But my
>> > post
>> > also had to do with how verbose REST responses are in general. I'd hate
>> > 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.
>> > And 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 return
>> >> what you need, like
>> >> On May 7, 2012 5:35 PM, "Brian Levine" wrote:
>> >>> Hello,
>> >>> I ran into this while using the REST API to add properties of a node
>> >>> to a
>> >>> full-text index. From the documentation (1.7), you can see that to
>> >>> add a
>> >>> property/value to a node index, one does:
>> >>> with a JSON payload including the URI of the node, the key and the
>> >>> value.
>> >>> On success, the response code is 201 and a Location header containing
>> >>> a URL
>> >>> of the form:
>> >>> 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 sure
>> >>> 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-verbose"
>> >>> 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
If you have to tunnel some other form within a REST API, it brings into question why you needed a REST API in the first place. But perhaps you're making the point that REST APIs are not well suited to database operations, which is certainly a very good point.
My scenario:
I am writing a Ruby on Rails application. I don't want to move to JRuby and so I can't make use of direct access to a Neo4j server. My only option at this point is to use the REST API, perhaps with one of the available Ruby bindings such as Neography. If I were using some RDBMS rather than Neo4j, I'd be using whatever Ruby driver is available for that database to provide remote communication. If I were writing a Java application against an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST API against the database itself.
So in short, I guess this a tension between whether REST is an appropriate remote communication mechanism for a database and the fact that it's the only thing available for Neo4j depending on the language in which your app is written. Maybe this is all leading to consideration of some other remote communication mechanism such as Thrift? Or maybe you're right and, if the only option is REST (at least for now), the best we can do is tunnel query language inside of REST.
My original post was about some of the issues I ran into as I began to learn your REST API, but before I started considering some of the meta-issues mentioned above ;-)
On Monday, May 7, 2012 12:54:22 PM UTC-4, Peter Neubauer wrote:
> 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.
> 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 wrote: > > This makes sense. Although 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. > > When even that's not sufficient either because it's not performant or > not > > expressive enough, using a query language with mutation support can be > used. > > However, I start getting worried when the only way to use a REST API is > 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
> >> 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. I was actually referring to the REST response I > >> > receive > >> > when *adding* an index entry as opposed to querying the index. But > my > >> > post > >> > also had to do with how verbose REST responses are in general. I'd > hate > >> > 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. > >> > And 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 > return > >> >> what you need, like
> >> >> On May 7, 2012 5:35 PM, "Brian Levine" wrote:
> >> >>> Hello,
> >> >>> I ran into this while using the REST API to add properties of a > node > >> >>> to a > >> >>> full-text index. From the documentation (1.7), you can see that to > >> >>> add a > >> >>> property/value to a node index, one does:
> >> >>> with a JSON payload including the URI of the node, the key and the > >> >>> value. > >> >>> On success, the response code is 201 and a Location header > containing > >> >>> a URL > >> >>> of the form:
> >> >>> 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 > sure > >> >>> 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-verbose" > >> >>> 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
> >> 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. I was actually referring to the REST response I > >> > receive > >> > when *adding* an index entry as opposed to querying the index. But > my > >> > post > >> > also had to do with how verbose REST responses are in general. I'd > hate > >> > 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. > >> > And 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 > return > >> >> what you need, like
On 7 May 2012 18:51, brian <blevine...@gmail.com> wrote:
> If you have to tunnel some other form within a REST API, it brings into
> question why you needed a REST API in the first place. But perhaps you're
> making the point that REST APIs are not well suited to database operations,
> which is certainly a very good point.
Being based on CRUD, the REST philosophy certainly has a large overlap with
typical database operations so I'd argue that it is a good fit. The only
place where this may not be true is when dealing with database
transactions, due to their stateful nature. We also shouldn't forget that
REST is merely an architectural approach and not a prescription for a
solution - the current incarnation of the REST API is still evolving and if
the consensus is that it's too verbose, it can easily evolve to become more
terse, while remaining RESTful.
> My scenario:
> I am writing a Ruby on Rails application. I don't want to move to JRuby
> and so I can't make use of direct access to a Neo4j server. My only option
> at this point is to use the REST API, perhaps with one of the available
> Ruby bindings such as Neography. If I were using some RDBMS rather than
> Neo4j, I'd be using whatever Ruby driver is available for that database to
> provide remote communication. If I were writing a Java application against
> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST
> API against the database itself.
You also have the option to build a server plugin if you can determine a
better method of communication for your use case. I'm slightly confused
about what you are actually questioning though - REST, JSON or simply the
absence of a binary protocol. The biggest issue we have found so far with
the REST API has been that of performance and there is already a
considerable amount of work going into looking at ways to improve this.
To be honest, this thread started with my concern that certain responses would be too verbose especially when property values are included in the path of URLs in the Location header or in the JSON response. So you can take that (FWIW) as specific feedback on the current state of the REST API. The rest (no pun intended) started because of Peter's suggestion that the work-around was to issue a Cypher query or send Groovy code over REST. I didn't really intend to question the use of REST or JSON in Neo4J. Yes, I'm aware that I can extend or wrap the server with a protocol of my choosing. It's just a small matter of some additional code ;-)
So leaving the discussion of some other remoting technology for some other thread:
- In general, I'd like to see the REST API support a terser representation. This could still be JSON, but maybe leaving out the links. - I think the fact that property/name values can appear in the path of a URI (especially URIs that the API returns in Location headers) is a bug since those (the values at least) can become quite large.
On Monday, May 7, 2012 4:55:12 PM UTC-4, Nigel Small wrote:
> Comments inline...
> On 7 May 2012 18:51, brian wrote:
>> If you have to tunnel some other form within a REST API, it brings into >> question why you needed a REST API in the first place. But perhaps you're >> making the point that REST APIs are not well suited to database operations, >> which is certainly a very good point.
> Being based on CRUD, the REST philosophy certainly has a large overlap > with typical database operations so I'd argue that it is a good fit. The > only place where this may not be true is when dealing with database > transactions, due to their stateful nature. We also shouldn't forget that > REST is merely an architectural approach and not a prescription for a > solution - the current incarnation of the REST API is still evolving and if > the consensus is that it's too verbose, it can easily evolve to become more > terse, while remaining RESTful.
>> My scenario:
>> I am writing a Ruby on Rails application. I don't want to move to JRuby >> and so I can't make use of direct access to a Neo4j server. My only option >> at this point is to use the REST API, perhaps with one of the available >> Ruby bindings such as Neography. If I were using some RDBMS rather than >> Neo4j, I'd be using whatever Ruby driver is available for that database to >> provide remote communication. If I were writing a Java application against >> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST >> API against the database itself.
> You also have the option to build a server plugin if you can determine a > better method of communication for your use case. I'm slightly confused > about what you are actually questioning though - REST, JSON or simply the > absence of a binary protocol. The biggest issue we have found so far with > the REST API has been that of performance and there is already a > considerable amount of work going into looking at ways to improve this.
On Monday, May 7, 2012 4:55:12 PM UTC-4, Nigel Small wrote:
> Comments inline...
> On 7 May 2012 18:51, brian <blevine...@gmail.com> wrote:
>> If you have to tunnel some other form within a REST API, it brings into >> question why you needed a REST API in the first place. But perhaps you're >> making the point that REST APIs are not well suited to database operations, >> which is certainly a very good point.
> Being based on CRUD, the REST philosophy certainly has a large overlap > with typical database operations so I'd argue that it is a good fit. The > only place where this may not be true is when dealing with database > transactions, due to their stateful nature. We also shouldn't forget that > REST is merely an architectural approach and not a prescription for a > solution - the current incarnation of the REST API is still evolving and if > the consensus is that it's too verbose, it can easily evolve to become more > terse, while remaining RESTful.
>> My scenario:
>> I am writing a Ruby on Rails application. I don't want to move to JRuby >> and so I can't make use of direct access to a Neo4j server. My only option >> at this point is to use the REST API, perhaps with one of the available >> Ruby bindings such as Neography. If I were using some RDBMS rather than >> Neo4j, I'd be using whatever Ruby driver is available for that database to >> provide remote communication. If I were writing a Java application against >> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST >> API against the database itself.
> You also have the option to build a server plugin if you can determine a > better method of communication for your use case. I'm slightly confused > about what you are actually questioning though - REST, JSON or simply the > absence of a binary protocol. The biggest issue we have found so far with > the REST API has been that of performance and there is already a > considerable amount of work going into looking at ways to improve this.
On Monday, May 7, 2012 4:55:12 PM UTC-4, Nigel Small wrote:
> Comments inline...
> On 7 May 2012 18:51, brian <blevine...@gmail.com> wrote:
>> If you have to tunnel some other form within a REST API, it brings into >> question why you needed a REST API in the first place. But perhaps you're >> making the point that REST APIs are not well suited to database operations, >> which is certainly a very good point.
> Being based on CRUD, the REST philosophy certainly has a large overlap > with typical database operations so I'd argue that it is a good fit. The > only place where this may not be true is when dealing with database > transactions, due to their stateful nature. We also shouldn't forget that > REST is merely an architectural approach and not a prescription for a > solution - the current incarnation of the REST API is still evolving and if > the consensus is that it's too verbose, it can easily evolve to become more > terse, while remaining RESTful.
>> My scenario:
>> I am writing a Ruby on Rails application. I don't want to move to JRuby >> and so I can't make use of direct access to a Neo4j server. My only option >> at this point is to use the REST API, perhaps with one of the available >> Ruby bindings such as Neography. If I were using some RDBMS rather than >> Neo4j, I'd be using whatever Ruby driver is available for that database to >> provide remote communication. If I were writing a Java application against >> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST >> API against the database itself.
> You also have the option to build a server plugin if you can determine a > better method of communication for your use case. I'm slightly confused > about what you are actually questioning though - REST, JSON or simply the > absence of a binary protocol. The biggest issue we have found so far with > the REST API has been that of performance and there is already a > considerable amount of work going into looking at ways to improve this.
Just one clarification, I should have using the term key/values rather than property/values since we're talking about adding index entries here which don't have to be based on a property of a node or relationship.
On Monday, May 7, 2012 5:26:21 PM UTC-4, brian wrote:
> To be honest, this thread started with my concern that certain responses > would be too verbose especially when property values are included in the > path of URLs in the Location header or in the JSON response. So you can > take that (FWIW) as specific feedback on the current state of the REST API. > The rest (no pun intended) started because of Peter's suggestion that the > work-around was to issue a Cypher query or send Groovy code over REST. I > didn't really intend to question the use of REST or JSON in Neo4J. Yes, I'm > aware that I can extend or wrap the server with a protocol of my choosing. > It's just a small matter of some additional code ;-)
> So leaving the discussion of some other remoting technology for some other > thread:
> - In general, I'd like to see the REST API support a terser > representation. This could still be JSON, but maybe leaving out the links. > - I think the fact that property/name values can appear in the path of a > URI (especially URIs that the API returns in Location headers) is a bug > since those (the values at least) can become quite large.
> -b
> On Monday, May 7, 2012 4:55:12 PM UTC-4, Nigel Small wrote:
>> Comments inline...
>> On 7 May 2012 18:51, brian wrote:
>>> If you have to tunnel some other form within a REST API, it brings into >>> question why you needed a REST API in the first place. But perhaps you're >>> making the point that REST APIs are not well suited to database operations, >>> which is certainly a very good point.
>> Being based on CRUD, the REST philosophy certainly has a large overlap >> with typical database operations so I'd argue that it is a good fit. The >> only place where this may not be true is when dealing with database >> transactions, due to their stateful nature. We also shouldn't forget that >> REST is merely an architectural approach and not a prescription for a >> solution - the current incarnation of the REST API is still evolving and if >> the consensus is that it's too verbose, it can easily evolve to become more >> terse, while remaining RESTful.
>>> My scenario:
>>> I am writing a Ruby on Rails application. I don't want to move to JRuby >>> and so I can't make use of direct access to a Neo4j server. My only option >>> at this point is to use the REST API, perhaps with one of the available >>> Ruby bindings such as Neography. If I were using some RDBMS rather than >>> Neo4j, I'd be using whatever Ruby driver is available for that database to >>> provide remote communication. If I were writing a Java application against >>> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST >>> API against the database itself.
>> You also have the option to build a server plugin if you can determine a >> better method of communication for your use case. I'm slightly confused >> about what you are actually questioning though - REST, JSON or simply the >> absence of a binary protocol. The biggest issue we have found so far with >> the REST API has been that of performance and there is already a >> considerable amount of work going into looking at ways to improve this.
> On Monday, May 7, 2012 4:55:12 PM UTC-4, Nigel Small wrote:
>> Comments inline...
>> On 7 May 2012 18:51, brian <blevine...@gmail.com> wrote:
>>> If you have to tunnel some other form within a REST API, it brings into >>> question why you needed a REST API in the first place. But perhaps you're >>> making the point that REST APIs are not well suited to database operations, >>> which is certainly a very good point.
>> Being based on CRUD, the REST philosophy certainly has a large overlap >> with typical database operations so I'd argue that it is a good fit. The >> only place where this may not be true is when dealing with database >> transactions, due to their stateful nature. We also shouldn't forget that >> REST is merely an architectural approach and not a prescription for a >> solution - the current incarnation of the REST API is still evolving and if >> the consensus is that it's too verbose, it can easily evolve to become more >> terse, while remaining RESTful.
>>> My scenario:
>>> I am writing a Ruby on Rails application. I don't want to move to JRuby >>> and so I can't make use of direct access to a Neo4j server. My only option >>> at this point is to use the REST API, perhaps with one of the available >>> Ruby bindings such as Neography. If I were using some RDBMS rather than >>> Neo4j, I'd be using whatever Ruby driver is available for that database to >>> provide remote communication. If I were writing a Java application against >>> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST >>> API against the database itself.
>> You also have the option to build a server plugin if you can determine a >> better method of communication for your use case. I'm slightly confused >> about what you are actually questioning though - REST, JSON or simply the >> absence of a binary protocol. The biggest issue we have found so far with >> the REST API has been that of performance and there is already a >> considerable amount of work going into looking at ways to improve this.
> On Monday, May 7, 2012 4:55:12 PM UTC-4, Nigel Small wrote:
>> Comments inline...
>> On 7 May 2012 18:51, brian <blevine...@gmail.com> wrote:
>>> If you have to tunnel some other form within a REST API, it brings into >>> question why you needed a REST API in the first place. But perhaps you're >>> making the point that REST APIs are not well suited to database operations, >>> which is certainly a very good point.
>> Being based on CRUD, the REST philosophy certainly has a large overlap >> with typical database operations so I'd argue that it is a good fit. The >> only place where this may not be true is when dealing with database >> transactions, due to their stateful nature. We also shouldn't forget that >> REST is merely an architectural approach and not a prescription for a >> solution - the current incarnation of the REST API is still evolving and if >> the consensus is that it's too verbose, it can easily evolve to become more >> terse, while remaining RESTful.
>>> My scenario:
>>> I am writing a Ruby on Rails application. I don't want to move to JRuby >>> and so I can't make use of direct access to a Neo4j server. My only option >>> at this point is to use the REST API, perhaps with one of the available >>> Ruby bindings such as Neography. If I were using some RDBMS rather than >>> Neo4j, I'd be using whatever Ruby driver is available for that database to >>> provide remote communication. If I were writing a Java application against >>> an RDBMS, I'd be using JDBC. So I no, I wouldn't expect to be using a REST >>> API against the database itself.
>> You also have the option to build a server plugin if you can determine a >> better method of communication for your use case. I'm slightly confused >> about what you are actually questioning though - REST, JSON or simply the >> absence of a binary protocol. The biggest issue we have found so far with >> the REST API has been that of performance and there is already a >> considerable amount of work going into looking at ways to improve this.
Just for information, a brief remark about my RailNet application that may be related to this thread. In this application ALL user interaction is done via the REST API wrapped in a few simple shell functions.
For the output part jsawk (https://github.com/micha/jsawk) is used to convert the verbose JSON responses in an awk-like fashion to nice lists or short to-the-point answers.
Further, to simplify user input, resty (https://github.com/micha/resty) is used in combination with a shell function to generate JSON input from user arguments.
> Just for information, a brief remark about my RailNet application that may be related to this thread. In this application ALL user interaction is done via the REST API wrapped in a few simple shell functions.
> For the output part jsawk (https://github.com/micha/jsawk) is used to convert the verbose JSON responses in an awk-like fashion to nice lists or short to-the-point answers.
> Further, to simplify user input, resty (https://github.com/micha/resty) is used in combination with a shell function to generate JSON input from user arguments.
> Any chance to share it? Or at least blog about it? That would be awesome.
> Michael
> Am 08.05.2012 um 09:52 schrieb Bert Fitié:
>> Just for information, a brief remark about my RailNet application that may be related to this thread. In this application ALL user interaction is done via the REST API wrapped in a few simple shell functions.
>> For the output part jsawk (https://github.com/micha/jsawk) is used to convert the verbose JSON responses in an awk-like fashion to nice lists or short to-the-point answers.
>> Further, to simplify user input, resty (https://github.com/micha/resty) is used in combination with a shell function to generate JSON input from user arguments.
That would be cool. Even Andreas Kollegger is playing around with a
very slimmed approach to interacting with the server, and Jake is
hacking on very fast HTTP without GC overhead, so there is a lot
boiling here. All approaches are welcome input to this discussion!
On Tue, May 8, 2012 at 10:21 AM, Bert Fitié <b...@analytag.com> wrote:
> If you think there is interest in this, I will try to find time in the coming weeks to write it up and make a link available.
> -- Bert Fitié
> On 8 mei 2012, at 09:54, Michael Hunger wrote:
>> Any chance to share it? Or at least blog about it? That would be awesome.
>> Michael
>> Am 08.05.2012 um 09:52 schrieb Bert Fitié:
>>> Just for information, a brief remark about my RailNet application that may be related to this thread. In this application ALL user interaction is done via the REST API wrapped in a few simple shell functions.
>>> For the output part jsawk (https://github.com/micha/jsawk) is used to convert the verbose JSON responses in an awk-like fashion to nice lists or short to-the-point answers.
>>> Further, to simplify user input, resty (https://github.com/micha/resty) is used in combination with a shell function to generate JSON input from user arguments.
> If you think there is interest in this, I will try to find time in the coming weeks to write it up and make a link available.
> -- Bert Fitié
> On 8 mei 2012, at 09:54, Michael Hunger wrote:
>> Any chance to share it? Or at least blog about it? That would be awesome.
>> Michael
>> Am 08.05.2012 um 09:52 schrieb Bert Fitié:
>>> Just for information, a brief remark about my RailNet application that may be related to this thread. In this application ALL user interaction is done via the REST API wrapped in a few simple shell functions.
>>> For the output part jsawk (https://github.com/micha/jsawk) is used to convert the verbose JSON responses in an awk-like fashion to nice lists or short to-the-point answers.
>>> Further, to simplify user input, resty (https://github.com/micha/resty) is used in combination with a shell function to generate JSON input from user arguments.
>> If you think there is interest in this, I will try to find time in the coming weeks to write it up and make a link available.
>> -- Bert Fitié
>> On 8 mei 2012, at 09:54, Michael Hunger wrote:
>>> Any chance to share it? Or at least blog about it? That would be awesome.
>>> Michael
>>> Am 08.05.2012 um 09:52 schrieb Bert Fitié:
>>>> Just for information, a brief remark about my RailNet application that may be related to this thread. In this application ALL user interaction is done via the REST API wrapped in a few simple shell functions.
>>>> For the output part jsawk (https://github.com/micha/jsawk) is used to convert the verbose JSON responses in an awk-like fashion to nice lists or short to-the-point answers.
>>>> Further, to simplify user input, resty (https://github.com/micha/resty) is used in combination with a shell function to generate JSON input from user arguments.
+1 on Brian's point that putting the indexed value in the URI is a
problem.. I'm not quite sure how to solve it, since the same entity can be
indexed with the same key and multiple different values, and we need a way
to address specific ones. Will put it into the backlog for consideration.
On the subject of limitations of rest, previous discussions have shown that
1) we can in fact properly introduce transactions in a RESTful way (see the
fast-http prototype) 2) that the overhead of the verbose API is a much
smaller part than the overhead induced by Jersey and jetty, in our internal
prototypes we have successfully improved performance more than 100-fold
without changing the data transferred over the wire
Jake
Sent from my phone, please excuse typos and brievety.
On May 21, 2012 8:12 PM, "Peter Neubauer" <peter.neuba...@neotechnology.com>
wrote:
> >> If you think there is interest in this, I will try to find time in the
> coming weeks to write it up and make a link available.
> >> -- Bert Fitié
> >> On 8 mei 2012, at 09:54, Michael Hunger wrote:
> >>> Any chance to share it? Or at least blog about it? That would be
> awesome.
> >>> Michael
> >>> Am 08.05.2012 um 09:52 schrieb Bert Fitié:
> >>>> Just for information, a brief remark about my RailNet application
> that may be related to this thread. In this application ALL user
> interaction is done via the REST API wrapped in a few simple shell
> functions.
> >>>> For the output part jsawk (https://github.com/micha/jsawk) is used
> to convert the verbose JSON responses in an awk-like fashion to nice lists
> or short to-the-point answers.
> >>>> Further, to simplify user input, resty (
> https://github.com/micha/resty) is used in combination with a shell
> function to generate JSON input from user arguments.
Found this oldish thread while searching for other things, but this is important, so I'll chime in: +1 for keeping the links! :)
After educating myself better on REST and HATEOAS, I'm rewriting my Neo4j perl client module to receive only the API entry point from the user, and discover everything else from the links in the answers. The rationale: semantic ties will last outlast harcoded strings tied to API versions.
On Sat, Jul 21, 2012 at 8:51 PM, nuba <nuba...@gmail.com> wrote:
> Hi folks,
> Found this oldish thread while searching for other things, but this is
> important, so I'll chime in: +1 for keeping the links! :)
> After educating myself better on REST and HATEOAS, I'm rewriting my Neo4j
> perl client module to receive only the API entry point from the user, and
> discover everything else from the links in the answers. The rationale:
> semantic ties will last outlast harcoded strings tied to API versions.
On Sun, Jul 22, 2012 at 4:51 AM, nuba <nuba...@gmail.com> wrote:
> Hi folks,
> Found this oldish thread while searching for other things, but this is
> important, so I'll chime in: +1 for keeping the links! :)
> After educating myself better on REST and HATEOAS, I'm rewriting my Neo4j
> perl client module to receive only the API entry point from the user, and
> discover everything else from the links in the answers. The rationale:
> semantic ties will last outlast harcoded strings tied to API versions.
In practice, quite a bit of knowledge is still required, e.g.:
- To get a node by ID, you have to know to append the ID:
"#{services.node}/#{id}"
- To get a relationship by ID, Neo4j doesn't convey the relationship
endpoint, so we construct it manually:
services.node.replace('node', 'relationship')
- We don't make a separate fetch to the index endpoint just to get the
template for the index URLs; we just do:
"#{services.node_index}/#{index}/#{key}/#{val}"
No great reason for this one btw. We just didn't see hardcoding a bunch of
template strings as that much better, plus that wouldn't prevent having to
know the POST params anyway, for adding to the index.
Just a few little things like that. Overall it's nice.
My one big feature request would be to have the returned URLs be
(root-)relative instead of absolute. That would make it easier to maintain
e.g. HTTP auth info in the URL, port forwarding, etc.
Aseem
On Sun, Jul 22, 2012 at 11:57 AM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:
> Nuba,
> cool! The Perl driver REST client will the first one to use these
> links for discovery, it would be very
> interesting to get your feedback on it!
> Wanna learn something new? Come to @graphconnect.
> On Sat, Jul 21, 2012 at 8:51 PM, nuba <nuba...@gmail.com> wrote:
> > Hi folks,
> > Found this oldish thread while searching for other things, but this is
> > important, so I'll chime in: +1 for keeping the links! :)
> > After educating myself better on REST and HATEOAS, I'm rewriting my Neo4j
> > perl client module to receive only the API entry point from the user, and
> > discover everything else from the links in the answers. The rationale:
> > semantic ties will last outlast harcoded strings tied to API versions.
> In practice, quite a bit of knowledge is still required, e.g.:
> - To get a node by ID, you have to know to append the ID:
> "#{services.node}/#{id}"
> - To get a relationship by ID, Neo4j doesn't convey the relationship
> endpoint, so we construct it manually:
> services.node.replace('node', 'relationship')
> - We don't make a separate fetch to the index endpoint just to get the
> template for the index URLs; we just do:
> "#{services.node_index}/#{index}/#{key}/#{val}"
> No great reason for this one btw. We just didn't see hardcoding a bunch of
> template strings as that much better, plus that wouldn't prevent having to
> know the POST params anyway, for adding to the index.
> Just a few little things like that. Overall it's nice.
> My one big feature request would be to have the returned URLs be
> (root-)relative instead of absolute. That would make it easier to maintain
> e.g. HTTP auth info in the URL, port forwarding, etc.
> Aseem
> On Sun, Jul 22, 2012 at 11:57 AM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>> Nuba,
>> cool! The Perl driver REST client will the first one to use these
>> links for discovery, it would be very
>> interesting to get your feedback on it!
>> Wanna learn something new? Come to @graphconnect.
>> On Sat, Jul 21, 2012 at 8:51 PM, nuba <nuba...@gmail.com> wrote:
>> > Hi folks,
>> > Found this oldish thread while searching for other things, but this is
>> > important, so I'll chime in: +1 for keeping the links! :)
>> > After educating myself better on REST and HATEOAS, I'm rewriting my
>> Neo4j
>> > perl client module to receive only the API entry point from the user,
>> and
>> > discover everything else from the links in the answers. The rationale:
>> > semantic ties will last outlast harcoded strings tied to API versions.
What is the case for absolute URLs? I imagine it could make sense if one is partitioning the database in some way, spreading the graph in more servers (sharding) and/or having specialized servers (e.g. one for the graph, another for the indexes). But even then, you could just use absolute URLs when needed, and stick to relative, or root-relative ones, as the default.
On Tue, Jul 24, 2012 at 3:18 AM, nuba <nuba...@gmail.com> wrote:
> What is the case for absolute URLs? I imagine it could make sense if one is
> partitioning the database in some way, spreading the graph in more servers
> (sharding) and/or having specialized servers (e.g. one for the graph,
> another for the indexes). But even then, you could just use absolute URLs
> when needed, and stick to relative, or root-relative ones, as the default.
peter.neuba...@neotechnology.com> wrote:
> You mean if a URL different than the current slef-URL of the server,
> to the full length, otherwise relative?
> Wanna learn something new? Come to @graphconnect.
> On Tue, Jul 24, 2012 at 3:18 AM, nuba <nuba...@gmail.com> wrote:
> > What is the case for absolute URLs? I imagine it could make sense if one
> is
> > partitioning the database in some way, spreading the graph in more
> servers
> > (sharding) and/or having specialized servers (e.g. one for the graph,
> > another for the indexes). But even then, you could just use absolute URLs
> > when needed, and stick to relative, or root-relative ones, as the
> default.
