Is there any reason why the default plug and play F# type providers to web services is soap based wsdl? Is it because of a lack of formal contracts in REST? Such that each REST api may differ significantly and hence making a general REST provider difficult to provide?
Type providers need machine-readable type schema to do their jobs well.
Type providers need schema. So you could use Open Data Protocol that is REST + schema. For that task you could use ODataTypeProvider that is already implemented.
I think that this is because there is no way to know how the API looks. Humans can read the documentation, but the Type Provider cannot. Other APIs have XML specifications, so they are easier.
Related
This is my understanding:
Swagger is a notation/rules to write documentation. But why is it called a framework (like Angular/MVC)?
Swashbuckle is a program (JavaScript?) that generates the documentation (based on Swagger rules).
Swagger UI displays the documentation. It uses Swashbuckle to do this.
Is this information correct? If not can someone explain in simple terms what Swagger, Swashbuckle, and Swashbuckle UI mean?
Also, what do I lose as an API developer if I do not use this?
Swagger is a notation/rules to write documentation. But why is it called a framework(Like angular/MVC)?
It is probably called a "framework" because its' purpose is to offer a systematic way of notating the interface of any RESTful service under the OpenAPI Specification. This is a big deal to developers because the spec is overseen by the Open API Initiative under the reputable Linux Foundation.
Swashbuckle is a program(javascript ?) that generates the documentation(based on Swagger rules)
Swashbuckle is more of a package (or a library) that you can make use of in your .NET Web API projects. It's purpose, as you have correctly indicated, is to generate the Swagger spec for your project. Additionally, the Swagger UI is contained within Swashbuckle so if you are developing an API in .NET it's really a nice one-stop shop of a package. It is almost entirely written in C#, not JavaScript.
Swagger UI displays the documentation. It uses Swashbuckle to do this.
Yes, it does display the Swagger spec in a nice, human-friendly manner. However, Swashbuckle is not a necessary component for this. They are, aside from what I just said previously, completely mutually-exclusive.
Also what do I lose as an API developer, if I do not use this.
This is now entering into the realm of opinion but I'll try to be objective about it. I use Swashbuckle to assist in the creation of clients for my application APIs. After getting past the implementation learning curve (which wasn't much), this package has saved me quite a bit of time of writing the clients myself. Writing a web client is a trivial thing for small applications but enterprise-level applications have a tendency to keep growing and/or changing in complexity so it is nice to have the creation/updating of these clients completely automated.
In short, if you decide not to use it you must either resort on an alternative method of API client generation or write/update the clients yourself. If you are only developing the back end this may be completely pointless to you but it would certainly help whoever is responsible for creating the client apps that will consume your API services.
I hope these answers have been helpful. Cheers!
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.
I'm a little bit confused that metadata doucment in OData Service.
As odata-v4.0-part1-protocol doc mentioned, there are two well-defined resources that describe its data model, a service document and a metadata document.
I want to know if that means both of these two resources must be implemented during development of OData Services, or developers just only need to implement one of them by their own choices?
I do appreciate anyone's help.
Thanks
Not necessarily. According to the "13.1 OData Service Conformance Levels" of OData V4 spec:
for minimal conformance level "MAY publish metadata at $metadata according to [OData-CSDL] "
for intermediate conformance level " SHOULD publish metadata at $metadata according to [OData-CSDL]"
for advanced conformance level "MUST publish metadata at $metadata according to [OData-CSDL]".
In other word, this means metadata is NOT a must for OData V4 service but service document is a MUST. If you have a deeper understand of OData, there are two kinds of OData libraries -- server and client, the metadata document of OData is for advanced client to know more about the service(models, types and so on). So having metdata document or not actually depends on whether you want your service to be talked to as much clients as possible.
my first question on StackOverflow, so apologies if not perfect right from the beginning ...
My question is actually two-fold:
Can I have the LightSwitch ApplicationData service (or any other internally defined Data Source) define ODATA actions on the service level or entity set/entity level? If yes, how do I do that? (I cannot find the route information in the application where I could override/add that.)
How would I consume these actions from the client side (via the built-in MS JS object model in msls or via screen/entity)? Even, if LightSwitch itself could not create/would not support actions, I would still like to know how to consume them from the client side, as we are exposing external ODATA data sources via LightSwitch to the client (and these ODATA source have actions defined).
I know I can use jaydata from the client side to consume that and execute actions on an ODATA source, but I would like to know if LightSwitch has built-in support for that.
Further information: we are using VS/LS 2013. And Silverlight is not an option, we only use the HTML client.
Thank you very much for your support and hints!
Regards, Ronald
There is nothing built-in to LightSwitch that lets you define custom OData actions on the service side or consume them from the client side. You'd need to use standard web functionality like ASP.NET's WebAPI and your favorite JavaScript OData library, like JayData.
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.