Can we use BreezeJS or JayData, with all of their features without OData (i.e using only ASP.NET Web API but without OData)?
Breeze already supports this as it's default. Breeze, by default, uses an OData format over the wire for query purposes, but this does NOT require that the server be implemented as an OData service. The standard Breeze WebApi server controller can understand this format without you having to implement an OData service. ( the same is true of our Mongo and Ruby server examples).
In fact, most of the Breeze examples show Breeze communicating directly with ASP.NET Web Api without using any of the WebApi OData implementation.
Related
I have some legacy applications that needs to call a new .net RESTFul API. What I am not sure of is if I can call a 4.51 API from a 2.0 web form.
For such a general question, I can give you a general answer.
Use HttpClient to make web requests to your REST API from your code behind, or make http requests from your javascript.
If you need to make requests to your REST API from your code behind, you will likely need JSON.NET to serialize the data from json to a .net object.
JSON.NET is available as a nuget package.
I'm new in elasticsearch. we have a project with a lot of user interaction. Backend of the project is ASP.NET MVC and frontend is Angularjs. Backend and Frontend communicate with WEB API.
We use SQL Server for data storage and we'll use elasticsearch for Search Engine and retrieving data from server.
Elasticsearch can work upon of Nest and javascript API, is there any difference in performance between Nest and JS API (Specially in very big and complicated queries)?
NEST, the high level Elasticsearch .NET client, uses Elasticsearch's json REST API through Elasticsearch.Net, the low level .NET client, and exposes all of the endpoints with strong types, using JSON.Net for serialization.
Elasticsearch.Net itself does not expose all endpoints with strong types but can work with string, byte[], object, and string, byte[] and object collections. It uses a simple json serializer to handle serialization so has no dependencies on any other serialization library.
NEST aims to be a fast client that "just works" for any scenario in which you want to use Elasticsearch. If you're using a limited subset of the API, you may be able to improve serialization with custom serializers using something like JIL, and, if the approach is generic, we'd love to know to see if it could be rolled into NEST. You can write your own json serializer by implementing IElasticsearchSerializer.
I am working on a SPA using Durandal, Breeze and Knockout. The back-end service is provided by ASP.NET Web API OData.
I have configured the Breeze to work with OData like this:
breeze.config.initializeAdapterInstances({ dataService: "OData" });
and have set the remote service name in Breeze to 'odata'.
The thing is that the uri that Breeze calls to get the metadata is odata/$metadata whereas the uri that seems to work properly (have tested in Fiddler) is odata?$metadata.
Am I missing something?
For Web API OData you should use:
breeze.config.initializeAdapterInstances({ dataService: "webApiOData" });
just odata is used for wcf odata.
We have some legacy OData service code in our application which is written using a WCF Data Service.
Everything else in our system now uses Web API as the data interface so I am wanting to port our WCF OData Service to a Web API service with the OData annotations.
My question is, we currently use the OData service for standard CRUD statements and also a lot of Service Operations. Are there any limitations with Web API OData that would limit it compared to WCF Data Services (i.e relationship chains, service operation calls, etc.)? I'm wanting to get away with updating the service so the client side of things doesn't have to change at all.
I've started working on a similar port from WCF to WebAPI for OData with the recent release of Web API 2 and its support for $select and $expand - until then I could not really replace the data service. Service operations can be added as actions
I have been catching up with MVC4 Web API and WCF Data Service. From the surface, they both seem to be able to work with oData in the consuming client. I wonder which one is better for separation of concern (separate data service layer from UI layers). In my current solution, I have a plain MVC 3 style Intranet project and a MVC Data Service project. The 1st project has a Service Reference to the 2nd project. My goal is to write the data service once and make it available to all projects that would need to access underline database. When I read about Web API, it seems to me that the ApiControllers can return oData compliant result to the consuming client without MVC Data Service. My confusion is how I am going to expose this Web API MVC project as a service endpoint. Should I wrap it in WCF? Thanks.
You just create a controller inheriting ApiController and decorate one action with [Queryable] attribute, Rest depends on your route setup. Easy-Peasy.
Which one better? Web API. Since it has all the goodness of HTTP and you are not restricted to ATOM format.
You may use PocoHttp for seamless access of the data from your client.