Is it required to use a RESTful
service to be able to make a ajax
call to a wcf service (for example: by using
WebInvoke attribute on Operation
contracts)
Once a service is made RESTful by adding a webHttp binding on the service host, can the host have other endpoints as well? (wsHttp or netTcp)
Is it required that the aspNetCompatibilityEnabled be set to true for a service that has webHttp binding (and can this setting coexist for other endpoints)
I understand I can use both JQuery and ScriptManager for making WCF calls on the client. Why should I use one over the other?
Answers
No.
AJAX is typically used for sending simple HTTP GET ("REST") requests. It doesn't have to be so. You could also format a payload using a SOAP envelope, and POST it to the endpoint. In that case the WCF service would have to be wsHttp or basicHttpBinding, at least. Here's an example of using VBScript to create and send a SOAP request, but you could do the same in Javascript. You can't use the more advanced SOAP extensions, like WS-Security, XML DigSig, and so on. Well, you could but it would be impractical. For example, I don't know of any XML canonicalization library in Javascript, which is essential for doing WS-Security or digital signatures. There are 17 similar obstacles. Result: you can't use the more advanced SOAP extensions when calling from Javascript.
.
If you use jQuery ajax, you'll need to use the beforeSend callback on the ajax request to set the SOAPAction header.
.
Having said that, it's a lot easier to process json in a Javascript program, than it is to walk the DOM of an XML document. In other words, you're better off using JSON/REST when connecting from Javascript to WCF, instead of SOAP. Sometimes it's not an option, I guess.
Yes
A WCF service can have multiple endpoints and they can listen on the same or different transports such as HTTP, net.tcp, net.pipe, or net.msmq.
No. aspNetCompatibilityEnabled just enables some ASMX-like features on the server. It affects how the service is designed, and it is independent of the message signature. It does preclude the use of non-HTTP protocols. For more on this, see Wenlong Dong's article.
as for which framework to use on the client - which is easier? I don't have experience with ScriptManager, but the decision criteria is pretty simple. jQuery works just fine, and is appropriate if you already use jQuery. If you don't have or want jQuery, you can use XmlHttpRequest to send SOAP or REST requests. If those are somehow inappropriate, use something else.
Related
There's one point in ASP.NET Core that I believe I didn't fully understand yet and that is the idea of request features. As explained in the docs:
Feature interfaces define specific HTTP features that a given request may support. Servers define collections of features, and the initial set of features supported by that server, but middleware can be used to enhance these features.
My initial understanding about this was that request features are all things a server should expose to be used on the application pipeline. That is, behaviors that a server should perform like sending a file.
On the other hand, there's, for example, the authentication request feature. Now, I'm not sure authentication falls into this category. It doesn't seem like some server behavior that the application should call, but rather, a concern of the application itself.
This makes me wonder what really makes something be a request feature. So, what makes something be a request feature in ASP.NET Core? Is my initial understanding wrong? What is behind the decision of making something a request feature?
My initial understanding about this was that request features are all things a server should expose to be used on the application pipeline. That is, behaviors that a server should perform like sending a file.
That's one use of http features. It's also a way to augment or light up behaviors on the HttpContext, like buffering, send file, authentication, websockets.
Middleware can also add features specific to that middleware, you can see examples of this:
The exception handler middleware flows the exception that occurred via a request feature - https://github.com/aspnet/Diagnostics/blob/dev/src/Microsoft.AspNetCore.Diagnostics.Abstractions/IExceptionHandlerFeature.cs.
The routing middleware adds route data to the current http context via a request feature - https://github.com/aspnet/Routing/blob/dev/src/Microsoft.AspNetCore.Routing.Abstractions/IRoutingFeature.cs
Generally it's a way to flow per request behavior and state from the server, through middleware, to the application.
I am already using the standard WebAPI and returning JSON objects to my client. Now I saw an application that returned OData.
Can someone explain if there is any reason for me to use OData if I do not want to query my data from anything other than my own client running in the browser. Are there advantages that I could get through using OData ?
If you are only using your data in your own browser application, there is only few advantages to use OData in your situation:
OData is able to provide metadata about your service interface that can be used to generate client code to access the service. So if you have lots of client classes that you need to create, this could speed up your process. On the other hand, if you can share your classes between the server and an ASP.NET based client or if you only have a few classes, this might not be relevant in your situation.
Another - bigger - advantage in your situation is the support for generic queries against the service data. OData supports IQueryable so that you can decide on the client side on how to filter the data that the service provides. So you do not have to implement various actions or use query parameters to provide filtered data. This also means that if you need a new filter for your client, it is very likely that you do not have to change the server and can just put up the query on the client side. Possible filters include $filter expressions to filter the data, but also operations like $skip and $top that are useful when paging data. For details on OData and queries, see this link.
For a complete overview about OData and Web API see this link.
Here are few advantages of OData.
OData is a open protocol started by Microsoft is based on Rest Services so we can get data base on URL.
It suppport various protocol like http,atom,pub and also support JSON format.
No need to create proxy classes which we used to do it in web service.
You will able to write your own custom methods.
It is very light weight so the interaction between client and server will be fast compared to web service and other technologies.
Very simple to use.
Here are few reference links.
http://sandippatilprogrammer.wordpress.com/2013/12/03/what-is-odata-advantages-and-disadvantages/
http://geekswithblogs.net/venknar/archive/2010/07/08/introduction-odata.aspx
http://www.zdnet.com/blog/microsoft/why-microsofts-open-data-protocol-matters/12700
I agree with the answers already posted, but as an additional insight...
You mentioned that:
... if I do not want to query my data from anything other than my own
client running in the browser...
You may not wish to run it normally through anything but your own cilent, but using oData you could use other querying tools for debugging. For example LinqPad allows you to use oData endpoints (such as that provided by stackoverflow).
It's probably not a good enough reason to implement oData if you don't have another reason to do so, but it's an added bonus.
Can someone explain the difference between the two, when to use WebScriptServiceHostFactory vs WebServiceHostFactory? I understand when used they setup certain default behaviors on the endpoints so I don't have to. Otherwise the differences, is it just the WebScriptServiceHostFactory defaults to JSON messages, while WebServiceHostFactory defaults to XML (soap messages)? Using WebGet and WebInvoke, do both work on them, or does one not allow it? Also can I use UriTemplates, to build REST services, with either one?
The WebScriptServiceHostFactory is used almost exclusively to define services that will be consumed by the ASP.NET AJAX framework (it gives the JS client a "proxy" which can be used to call the service). If you're doing general-purpose WCF web (REST) programming, you should stick with the WebServiceHostFactory.
Some differences:
As you mentioned, the default response format is different (JSON in WScriptSHF, XML in WSHF)
UriTemplates are fully supported in WSHF, not in WScriptSHF
WebGet and WebInvoke work on both, but on WScriptSHF the only supported body style is WrappedRequest
Responses to calls to an endpoint created by WScriptSHF are wrapped in a JSON object; if the response to an operation (in JSON) was [1,2,3], the endpoint will return it as {"d":[1,2,3]}.
There may be others, but essentially, the guidance is to use the WScriptSHF only if you're using the ASP.NET AJAX framework (with the <asp:ScriptManager>) and the WSHF for everything else.
I am aware of Web Services and WCF but I have generic question with services.
I have a ASP.NET MVC Application which does some basic functionality. I just have a controller in which I am passing it the records and serializing the information to XML using XML Serializer. Then I return this information to the browser and it displays me the XML i got from the Controller Action. So I get the XML representation of my Class(Database Object) in XML and I am to give the URL of this application to the client and access and pull the information.
Is this a Service then?
I mean in the end all the Clients need is the Xml representation through services also right? I am not that experienced and probably being very silly but please help me out...if I provide xml this way to the client is that a Service? Or is there something I need to understand here?
Don't let all the buzz about "web services" fool you; the basic idea behind a web service is very, very simple. It is simply a matter of providing data in response to a request over standard web transport protocols (i.e., HTTP/HTTPS). Everything else (XML, SOAP, WSDL, etc.) is just layered technology to augment the basic functionality of a service. REST-based services are very basically the simplest services that you can build--they are built on the core HTTP/S transport protocol and not much else.
The main differentiator between a service and traditional web site is that a service is data-focussed rather than presentation-focussed; that is, services typically are not concerned with how data is formatted and displayed (that is up to the client), but rather what data is returned. So...you are delivering XML data over HTTP? Check. You have a service. Congratulations!
Yes, it is a service, returning an XML resource. Also it seems that it is accessible throught standard HTTP verbs such as GET, so one might assume it is RESTful. The difference with a standard SOAP XML service is that you don't have a WSDL that describes it, so you might need to provide a good documentation to clients wishing to consume your service.
Our web services are distributed across different servers for various reasons (such as decreasing latency to the client), and they're not always all up-to-date. Rather than throwing an exception when a method doesn't exist because the particular web service is too old, it would be nicer if we could have the client check if the service responds to a given method before calling it, and otherwise disable the feature (or work around it).
Is there a way to do that?
Get the WSDL (append ?wsdl to the URL) - you can parse that any way you like.
Unit test the web service to ensure its signatures don't break. When you write code that breaks the method signature, you'll know and can adjust the other applications accordingly.
Or just don't break the web services and publish them in a way that enable syou to version them. As in http://services.domain.com/MyService/V1.1/Service.asmx (for .NET) so that way your applications that use v1.1 won't break when you publish v1.2 and make breaking changes.
I would also check out using an internal UDDI server if it's really that big of a hasle to manage your web services. Using the Green Pages of UDDI will tell you what you want to know about the service.
When you are making a SOAP request you are just sending an HTTP request to a server. If the server understands it, it will respond with an HTTP 200 and some XML back, if it doesn't it will send you some error HTTP code (404, 500, ...)
There is no general way to ask for the existance of a "method" exposed by a web service. Try to use the WSDL exposed if it is automatic, or just try to use the "method" and check for an error in the response (you don't have to send an exception to the user...)
Also, I don't know if I understood you well, but you are thinking of quering the server twice, once to check if the method exists, and second to make the actual call it if it does? I would just check for the error if it doesn't, and proceed normally if it does.