Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Is there a good comparison of GraphQL & OData in terms of performance, developers usability, community, etc.. All articles that I find in the Internet are very bias.
What would be the best way to return a big bulky JSON or binary data?
I have researched and also tried with Both GraphQL in Dot Net and Odata in DotNet Web API to create a working demo and What I found are
Developer Usability Considering you have existing WebAPI(DotNet Framework) and want to migrate to GraphQL or OData compatible WebAPI then my answer is to choose OData because of its easy integration and Out of the Box Filter, OrderBy, Select, Expand, etc feature (Refer MSFT On DotNet OData). If you choose GraphQL then you have to do a lot of work like Create Type, Schema and Query and Implement Resolver for each query.
Performance depends on your query logic. GraphQL and Odata Both have the capability to get what you request using $select in OData and in GraphQL you can request by their Query convention.
API Development From Scratch, If you want only single endpoint for all API request and don't want to maintain versioning endpoint, Autosuggest field name and type of schema then GraphQL is the best option. But Availability of GraphQL Library for Each framework and Community varies for Technology stack(e.g. nodejs, C#, Ruby, Java etc)
Yes, I have reviewed and read article by Telerik which have described in detail.
Comparision PDF For GraphQL and Odata
I am attaching side by side comparison image only you can dig out detail in Reference link GraphQL vs OData.
Standard API
Here, No in API Versioning/ maintenance is positive meaning single endpoint and get rid of two versioned API
Query Capability
Surface Capability
Mainly OData service is used when you want to provide access to your database with minimal effort for CRUD Operation.
However if you aware about Sharepoint REST API and Office 365 REST API It is based on OData and provides a wide range of API. Now Microsoft is building universal API which is called Graph API or Microsoft Graph which by default enabled for CORS request and unified endpoints to Request from Office 365, dynamics 365, Outlook Exchange API, Onedrive API etc. Which are also supports OData.
It also does not seem like a good idea to use the POST method to request data. And apparently the amount of data needed to make a request to the server is much greater. According to examples from the Sumit Sarkar article:
The amount of data trafficked to make a request is much greater in GraphQL than in OData. Although, the result (response) is the same.
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.
Looking at data access for a multitenant SaaS database for a UI5 app I have two choices - JSON or OData. OData has some features of interest. However, I have concluded that I cannot use OData because of security issues.
In particular I am concerned that OData is a form of query language. As a very rough comparison this is like a SQL statement being composed at the client and sent to an ODBC server for processing. In a multitenant DB I will separate data between owners using, say, and org_id. If it were a SQL query I would have to include select data from table where org_id=this_tennant and .... If I can discover another tenants org_id then I can use an OData explorer to modify the query and pass into the OData source.
In a JSON data interface I would call a REST method that would mask how the data is accessed, and I would not need to expose secret details such as the org_id token. Granted the JSON / REST approach involves more work.
Or do I misunderstand OData ?
Another similar question was asked some time ago but some time has passed so I shall ask again.
The approach of OData is to define how RESTful APIs can be build. It adds a lot of concepts and conventions (e.g. entity types and sets, URL conventions, common query parameters, request format, batch support...) to plain REST and therefore provides you a standard for building your API.
However, it does not define where your data is coming from, but in most cases it will be database. Of course it would be possible to expose your database tables via an OData service in a generic way, but I would expect that the provider of the framework clearly describes how to handle and protect different tenants.
A more specific answer would require more information about the framework you will use.
I have a Web API using OData that I need to query. The client application is a SPA built with React/Redux, but it looks as if most data service libraries such as isomorphic-fetch do not support OData. Can BreezeJS be useful for me in this situation? Or OLingo's ODataJs? Any examples, tutorials, resources on using these or any other OData clients with Redux? AFAIK, I just need a the client library to query an OData source and support promises. And as far as the data I get back from the server, I just need simple json objects; no need for models that support binding.
I've seen discussions of Breeze + Angular/Backbone, but can it support Redux/React?
I doubt that either Breeze or ODataJS supports ES6, so if i had to wrap them in a ES6 module, would they still function properly?
Maybe it helps if you consider that OData isn't that far off from REST. If it's just about pulling the data from a OData service, you won't need much more than jQuery.getJSON and Breeze will work too. However, if you want to do it the fancy way, and want you app to introspect the meta-model and such, you should have a look at datajs or olingo.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
ASP.NET web api: documenting/specifying a service
I'm new to Asp.net Web API. It seems there is no formal definition of the input and outputs for the Web APIs, unlike SOAP-based ones where a WSDL document contains all the schema required for requests and responses to the service. I am very familiar to this concept due to my past experiences in WCF.
How a client knows how to consume those APIs ? Does we need to provide 'examples' ?
I think your best bet is to go for ASP.NET Web API Help Page nuget package - http://nuget.org/packages/Microsoft.AspNet.WebApi.HelpPage. It's been released the same day as Web API RTM was released, that's why there is no so much info on the web about it yet, and why most people would still point you to IApiExplorer.
There is a really nice introduction screencast by Yao Huang from MSFT about how to use it - http://blogs.msdn.com/b/yaohuang1/archive/2012/08/15/introducing-the-asp-net-web-api-help-page-preview.aspx
It's not as low level as IApiExplorer (it operates on top of that) and should be more than fine for most use cases.
Also, if you are building a REST service do not use WSDL. It has not been designed to document REST services, and its much closer to RPC type of API.
ApiExplorer is the way to go for Asp.net Webapi.
Since there is no WSDL or anything for REST Apis that can exactly tell the consuming client about the operations/ contract exposed. Webapi had IApiExplorer that can be used for generating documentation of your api
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am designing a system that will be running online under Microsoft Windows Azure. One component is a REST based web service which will really be a wrapper (using proxy pattern) which calls the REST web services of a business partner, which has to do with BLOB storage (note: we are not using azure storage). The majority of the functionality will be taking a request, calling our partner web service, receiving the request and then passing that back to the client.
There are a number of reasons for doing this, but one of the big ones is that we are going to support three clients: our desktop application (win and mac), mobile apps (iOS), and a web front end. Having a single API which we then send to our partner protects us if that partner ever changes.
I want our service to support both JSON and XML for the data transfer format, JSON for web and probably XML for the desktop and mobile (we already have an XML parser in those products). Our partner also supports both of these formats.
I was planning on using ASP.NET MVC 4 with the Web API. As I design this, the thing that concerns me is the static type checking of C#. What if the partner adds or removes elements from the data? We can probably defensively code for that, but I still feel some concern. Also, we have to do a fair amount of tedious coding, to setup our API and then to turn around and call our partner’s API. There probably is not much choice on it though. But, in the back of my mind I wonder if maybe a more dynamic language would be a better choice.
I want to reach out and see if anybody has had to do this before, what technology solutions they have used to (I am not attached to this one, these days Azure can host other technologies), and if anybody who has done something like this can point out any issues that came up. Thanks!
Researching the issue seems to only find solutions which focus on connecting a SOAP web service over a proxy server, and not what I am referring to here.