I need some conceptual understanding of Neo4j REST api's usage. I went through the tutorial of neo4j RESt api and got some idea. So is it like these REST api's are used only to CREATE nodes and Relationships and also to fetch data from the neo4j graph database? So can you give me one example/scenario where and how these neo4j REST api's are used?
Thanks,
Shree
Historically the very granular REST API calls for e.g. creating nodes, setting properties were there before Cypher was established. Cypher is a way more concise and compact way to query and modify the graph compared to the granular REST calls. These days you typically use Cypher over the transactional http endpoint.
For some usage examples refer to the manual as well.
Related
SharePoint Online can be accessed either using SharePoint's own native REST API, or, using Microsoft Graph API. I have briefly explored both of the APIs and see differences in terms of the capability, for example, SharePoint API has function type method calls (GetByTitle()), whereas the Graph API seems to support identity based access, or, 'site path'. My opinion is that SharePoint makes it easy to access resources through the use of 'function' in URL, however, i am not sure if it is RESTful. It would be helpful to have your views on this aspect.
Given the two options (SharePoint & Graph) which is the recommended way forward, considering below criteria's:
Future proof - in terms of enhancement, support from Microsoft
Performance
Functionality coverage - considering current version of Graph API
Also, I couldn't find any Microsoft recommendations on this, if there is one kindly share the link.
Thanks.
I recommend Microsoft Graph API. I know it is a proxy to actual Sharepoint, OneNote, Planner, and etc API, but the way they are improving graph api day by day makes me think it is going to last for a good time. Let's say if you are writing an app that wants to connect with many Microsoft apps endpoints, having one class that handles all the graph api requests is enough instead of looking for specific apps endpoints.
Performance: I have been using Microsoft graph api for most of SharePoint related work and it works good and fast. I use Graph explorer to check out the graph if it actually works before implementing it in the app.
Functionality Coverage: Obviously graph is a proxy of a real api so it won't cover all the processes you need to do in SharePoint. For example, I had to create a Sharepoint Group which I could not find a way via graph api. But I assume as more people vote on those requests, the graph api is bringing those new possible proxy endpoints too. But again if your app is only working with Sharepoint then I believe I would stick to SharePoint API. In favor of Graph API, they also have something called delta query and subscription notification to see changes in the files and documents.
I was under the impression that the Graph API was meant to centralize things, make one endpoint to connect to all Sharepoint services via API. With that in mind, I wonder if we shouldn't be asking which is the better option but rather we should be asking when the so-called native option will be end of lifed. Graph is more future proof in the sense that this is the direction MS is taking. I can't speak to performance personally. As far as functionality, I can't imagine that Graph is functionally worse than previous iterations of SP. It might be functionally different. But it should expand API functionality.
This Microsoft's documentation page: https://developer.microsoft.com/en-us/graph/docs/concepts/deployments indicates that support for Delta queries against Microsoft Graph API varies across different resources on each national cloud deployment.
I would like to know exactly which deployments support Delta queries against Microsoft Graph API, but I couldn't find any documentation about this.
As you discovered, we don't currently document which clouds support delta query.
If you're willing to do a bit of investigating, I can show you a trick to see not only which clouds support delta query but also which specific endpoints support delta query.
You can send metadata requests to each cloud like https://microsoftgraph.chinacloudapi.cn/v1.0/$metadata or https://graph.microsoft.com/v1.0/$metadata. Note that these requests don't require an access token in the header so you can actually just open these links in your browser.
Search this XML for delta and you'll see our delta function definitions. For example, the following says that the user collection (GET /users) supports delta query.
This one means that groups supports delta query.
Does Spring Data provide a way to create new nodes via a REST endpoint? I don't think so but would like to make sure.
Which version are you referring to?
SDN works in both versions also with Neo4j server but using the Cypher Endpoint under the hood.
I know that neo4j database can be used both as embedded or server.
In neo4j documentation it says that REST API has an endpoint for Cypher queries, so if I issue Cypher query using spring-data-neo4j #Query annotated method, this query is sent to the database, executed on database side and then the result is sent back.
What about traversal API then? If I would submit traversal description using
findAllByTraversal(N startNode, org.neo4j.graphdb.traversal.TraversalDescription traversalDescription)
does it send all traversal description to the server and executes it in server context (so there it is only one HTTP request)?
Traversal API (package org.neo4j.graphdb.traversal) is only available via Java API. To expose your code using traversal API via REST, the recommended way is to wrap it into a unmanaged extension.
Say I have the following model
I would like to present a unified front for these OData feeds to my clients.
Is there a nice way with OData to do this? Or should I just take IQueryables from the OData feeds and make a reflection endpoint on top of these?
If I use the reflection stuff on top of the OData that talks to the database (via Entity Framework) what kind of problems am I going to encounter?
I would not use the reflection provider over the client library, mainly because the client library LINQ provider doesn't support all the constructs used by the server. As a result some queries would simply not work at all (projections and expansions usually get broken).
Assuming you don't want to create any associations between the databases, you should be able to simply point the users at the right service. You can still expose something which looks like a unified endpoint without the need of having the same URL for all of them.
The main idea is that you unify the $metadata (if your model is static you can do this manually, if not you should be able to write some kind of "merge" tool pretty easily) and then provide a service document which points to the respective URLs for each entity set. In the WCF Data Services client, there's now support for these kind of services through entity set resolver: http://blogs.msdn.com/b/astoriateam/archive/2010/11/29/entity-set-resolver.aspx
The latest CTP with that support is here: http://blogs.msdn.com/b/astoriateam/archive/2011/06/30/announcing-wcf-data-services-june-2011-ctp-for-net4-amp-sl4.aspx
Not happy with the current accepted answer for this question, for me it's more of an anti-answer, of what not to do. My solution here applies as much today as it did in '11
To support a tenancy scenario, where each user/client data will always reside on the same Database, and the data schemas all match then all you need to do is change the connection string when the data context is instantiated.
Another term for this concept is Sharding, MS have some tools and APIs that can help, This is a simple enough walkthrough: Azure SQL Database Elastic database tools: Shard Elasticity but you can do this pretty easily from first principals.
If swapping out the connection string will work for your scenario we need to identify the mechanism that you will use to determine the connection string, there are two common solutions to this:
The simple way out is to use fixed host headers, a route or token in each request to the service, then you can hardcode the logic for determining the connection string without complicated mapping logic.
Use a master / header / mapping DB to store your configuration.
This database has a separate schema that's primary purpose is for retrieving the correct connection string for each request.
In most cases we combine this with the Authentication process, in which case
you keep the authentication in this central database, not in the individual databases.
In terms of the OData Controller, even with WCF Data Services, you just need to implement your logic for retrieving the connection string and use that when you instantiate your data context.
Of course, this doesn't help you if your client's data is spread across multiple databases, but it is a pretty common pattern for sclaing out large databases withough having to deploy a new farm of services for each database.