I have a WCF webservice developed with .NET 4.0 which I need to be called by a Javascript client. I have been searching online for the best binding to use to make this possible. Most answers seems to point towards webhttp, but I am concerned as this is one of the lest secure bindings. What is the best way to configure this?
As per my experience and understanding of "invoking wcf service from client side using jquery", i would say:
You can use either of webhttp or basichttp binding if need to invoke using jquery/javascript (surely basichttp better choice over webhttp here).
One person even wrote an article on codeproject where mentioned that using jquery one can even invoke wshttp bidning based wcf, I have not tried it myself, so not sure about it but if you need to expose your service with wshttp, then can refer this link on CP:
http://www.codeproject.com/Articles/311908/Calling-WCF-service-exposed-with-different-binding
In my opinion i would say:
if there is no business need to expose service as rest one, then don't go for webhttp, Again if your client app is NOT a .net app and if there is no need to have security in place, then you can avoid wshttp totally, so per this i would say go for basichttp bidning, where you get interoperable service and can even add security in future, if needed.
Quick testing your WCF webservice you can install "Advance REST client", it's available for Chrome/Firefox.
In order to integrate with your JS client app, you can use jQuery http get post depending upon your WCF verb. Alternatively, you can also use Angular.JS for the same, e.g., $http.get
For security you can secure your service endpoints in .net
Take a look at this page which specify different security configurations you can use in wcf.
What is your javascript client? is it running in browser?
Related
When I am creating a simple website with node.js I am fine with using the view engine (eg. jade) and controllers that provide data to it (eg. simple todo list). However, if I decide to add AngularJS as the client framework then it seems that I must implement REST API on the backend to get data from it. Almost all examples I see online with AngularJS have this basic architecture: client (angular) communicates with the server via REST API.
Can AngularJS be used without REST API and if so should I do it or should avoid it? Are there any recommendation/best practices for using AngularJS without REST API backend?
Absolutely. Angular can still do a lot on your site even if you never utilize the $http service to talk to your server. You can still take advantage of the utilities for helping out with managing your DOM.
That said, most modern apps need to get data from the server. There are tons of reasons why you might need to do this. For example, if you had users that needed to sign up then you'd need to store their username and password somewhere. That somewhere would be in a database that only your server can access. Then your server would provide some URLs that you can talk to via Angular's $http service.
If you do have an app that makes calls to the server but you want to turn off the network communication for testing, you can mock the $http call responses. Angular provides an $httpBackend for that exact purpose. You can use it to set up dummy URLs that pretend to respond to your $http calls so that your $http calls don't know they aren't actually talking to a server.
authRequestHandler = $httpBackend.when('GET', '/auth.py')
.respond({userId: 'userX'}, {'A-Token': 'xxx'});
Perfect for testing your code without a REST backend during testing.
REST which is short for Representational state transfer is basically things or resources instead of actions. Yes AngularJS can be used without REST API.
You can use nodeJS for your restful API and AngularJS as your javascript framework.
Even without a restful API AnguarlJS is a very strong tool to use in a project although to use it to it's full potential (fully scaled web app) then you would need a restful API.
use $http for not RESTful API
use $resource for RESTful API
I have a simple one page HTML website to get user input and a WCF service that takes user input and return a list of strings depending on the input.
I would really appreaciate any guidance to connect the two together. Can it only be done with httpBinding and JSON serialization? Is JSON the best practice in this case?
If so, how do I make calls to the service? Do I need any server side scripting or is javascript on the client side enough?
If so, how do I capture and output the return of the service?
Thanks a lot.
Generally I use Ajax Enabled Wcf Service, with Json in this case. It works great for me
Most of times it's too much unnecessary complication of the system when you create a WCF service, define bindings, endpoints, contracts, host the service and distribute the client when you could simply get the things done with ASP.NET Page Methods + jQuery even getting rid of ScriptManagers.
You can call a Page Method directly from any .html file, you just need to have a single aspx file on the server, users may even don't know about its existence. The method can return your strings in a single string value, separated with any comma-like sign which is processed by JS later on.
You have a great advantage with page methods, 'cause the service is built into the asp.net web application, you're free of heavy, time-consuming mechanical hand-work every time you have to modify the service. My strong recommendation for you is to make use of page methods if you have an asp.net web app and follow KISS principles.
I want to use WCF to expose my data layer.
I want to use this WCF in WPF project and Web application.
So i can call this service using javascript or jquery.
But one thing I could not understand that using WPF and wcf is not problem and is very flexible.
Means I am able to create DataContracts and Service Contracts and then later will decide on endpoints etc.
But so far my understanding is that to use using javascript I have to convert wcf into wcf rest services, by adding attributes to the Service Contracts.
Does not this breaks the whole principle of SOA using WCF, where I create WCF and using configuration will be able to use with any application silverlight, wpf, asp.net, php etc
and how I will be able to reuse my wcf data constarcts and service contracts code.
Thanks,
Daljit Singh
Please take a look at WCF Data Services. This toolset allows you to quickly and flexibly have both JSON and XML formatted access to your data layer using the REST protocol. The fact that you choose REST does not mean it is not SOA. And REST is supported very nicely also in WPF. REST just fixes your protocol to http.
For a discussion on REST versus SOAP, please read http://blog.tonysneed.com/2010/04/13/wcf-data-services-versus-wcf-soap-services/.
I'm about to create a JavaScript-based client for a RESTful webservice. The client should facilitate access to the webservice and wrap some raw HTTP calls into more "candy" functions and objects.
I'm intending to use this client library for node.js-based applications as well as for PhoneGap. So, I don't have to care about the Same-origin-policy. However, dispatching HTTP requests is totally differnt in PhoneGap and node.js.
Now I'm wondering how I can implement a client library in JavaScript, that is portable between different "platforms" (node.js, PhoneGap, perhaps later even browers)?
Thanks in advance
You might try this emulation of XmlHttpRequest under nodejs but you still may need to special-case your client library to operate under PhoneGap (and other browser-based JavaScript platorms) and nodejs.
One way to do this would be to check the contents of 'window' which is undefined by default under nodejs, or 'global' which is (should be) undefined in a browser.
EDIT
It appears I spoke(wrote) too soon. Check out abstract-http-request which while not explicitly supporting PhoneGap, might give you enough to work with.
Phonegap is basically just a browser. So if you want to get around the same origin policy you might want to take a look into different phonegap plugins (GapSocket) to handle your own communication.
REST is an architectural style for designing web services. A web service doesn't have to use HTTP to be RESTful, though a large proportion of them do. To be RESTful, an HTTP-based web service has to rigorously leverage HTTP's resource names (URIs), operations (GET, PUT, DELETE, etc), error codes (404, 200, ...), and so on. This means that any (HTTP-based) REST client framework can interoperate with any (HTTP-based) REST server framework: if it doesn't, something's probably wrong. So your problem decomposes into finding a good generic REST client framework and one or more generic REST server frameworks.
For node.js based web services, take a look at the Geddy server-side framework (here's the documentation).
For a PhoneGap REST client, you could try the Force.com JavaScript REST Toolkit (and see this extension).
Disclaimer: I have only read about these frameworks, not used them.
Does anybody know of a way of checking on the API side if a XMLHttpRequest has been made from my own web-application (ie. from the JS I have written) or from a third-party application...
The problem, to me, seems to be that because the JS is run on the client and thus accessible to anyone I have no way of secretly communicating to the API server who I am. I think this is useful because otherwise I cannot prioritize requests from my own application over third-party clients in case of high usage.
I could obviously send some non-documented parameters but these can be spoofed.
Anybody with some ideas?
I would have your web server application generate a token that it would pass to your clients either in JavaScript or a hidden field which they in turn would use to call your API. Those with valid tokens get priority, missing or invalid tokes wouldn't. The web server application can create & register the token in your system in a way that limits its usefulness to others trying to reuse it (e.g., time limited).
If you do approve of third party clients accessing your API, perhaps you could provide them with a slightly different, rate-limited interface and document it well (so that it would be easier to use and thus actually be used by third-party clients).
One way to do this would be to have two different API URLs, for example:
/api?client=ThirdPartyAppName&... for third-party apps (you would encourage use of this URL)
/api?token=<number generated from hidden fields from the HTML page using obfuscated code>&... for your own JS
Note that as you mention, it is not possible to put a complete stop to reverse engineering of your own code. Although it can take longer, even compiled, binary code written in such languages as C++ can be reverse engineered, and that threatens any approach relying on secrecy.
A couple of ideas come to mind. I understand that secrets never last, so I agree that's not a good option.
You could run another instance on a different unadvertised port
You could do it over SSL and use certs to identify the client
A simple but less secure way would be to use cookies
You could go by IP address, but that could be an administrative nightmare