-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for REST format #13
Comments
Sorry I missed this issue! I think your'e totally right! Which is awesome since it'll save some processing :) I'll take a look when I can. If the REST format were requested, would we just emit the responses verbatim? |
Suh-weet, thanks! You'd still do the dictionary-ifying thing ( |
Removed the extractData method: brian-gates@1c00cf3 |
In pull #16, I didn't generalize this to |
Quick bug first:
extractData
recursively calls itself if an object has adata
property, so this means it'll incorrectly drop legitimate property data if there happens to be a property nameddata
. =)But wait! That bug's not worth fixing, because (I think) you don't even need that function anymore, since the transactional endpoint returns just property data by default now. So you should just remove it.
But on that note, I'd like to request an option to return the REST format instead of the lean property-only format. Having node and relationship metadata is needed for ORM/OGM-type libraries.
Easy enough to request it:
http://neo4j.com/docs/stable/rest-api-transactional.html#rest-api-execute-statements-in-an-open-transaction-in-rest-format-for-the-return
This could potentially be just another option to add to #10's options-based API, e.g.
format
.WDYT? SGTY? ORLY?
The text was updated successfully, but these errors were encountered: