I have wirtten a RESTful WCF Service. Incorporating E-Tags, expires headers.
The caching works great when using it from a browser. However how does the caching work when calling it from a WCF Channel Factory or .NET Web Request Objects?
So in the scenario where I have my website calling the WCF restful service when a 304 not modified response is returned to me. How do I handle this. The browser detects this fine and returns the unmodified version from its cache.
However when the client is not the browser do I need to write my own version of the cache similiar to the way the browser caches?
Any help or insight would be much appreciated.
Yes, you're going to have to handle that yourself, same as that you're responsbile for sending the datetime in the request, so the server can determine if there was a change. I would look at the RSS Bandit source for a sample implementation.
We have a sample that illustrates how to do this (using .NET 4) http://code.msdn.microsoft.com/cannonicalRESTEntity
Related
Currently i working on Creating WCF service in order to communicate xamarin forms (Android) with sqlserver. For that i have tried some examples from the following link https://developer.xamarin.com/guides/xamarin-forms/web-services/consuming/wcf/ but it was not working also it throws error(SystemError).
My goal : i have to retrieve data from sqlserver using WCF service . Kindly provide ideas to solve this issues.
Thanks.
krupa
i think you want to create web-service, you can learn how to make wcf from here
webservices is same like an other client-server architecture where you send request to server and get response.
now make one hello world webservices base on above example
Request - in request you have to send data you can use xml or json
in method of webservice you have to process your data [calculate/store in DB/etc]
in response you send response data back
*to test a webservice use postman extension in chrome browser
I have a qooxdoo web application which should be able to request data from a WCF web service. The WCF service uses SOAP. I'm currently looking for a way to set up the communication between my qooxdoo application and the WCF web service.
Is there a way to get this done? I saw that qooxdoo is supporting REST and I'm looking for something like a SOAP module in qooxdoo.
Thanks in advance!
There's an ancient contrib, probably unmaintained, at http://svn.code.sf.net/p/qooxdoo-contrib/code/trunk/qooxdoo-contrib/Soap/0.5.1/. You might not be able to use it right away, but I think the source code there will need just a few changes to become usable.
i'm about to begin a WP7 project. i currently have a WCF REST service deployed on my LIVE servers, and my Android and iPhone clients are happily consuming this. how do i get my WP7 to communicate with my REST service? The server side is working fine and well, and there is no issue there.
what i thought i would be able to do was simply add my client library (compiled in SL) with all the interfaces, datacontracts etc, create a ChannelFactory, ensure the web behavior was on in the client and yay! away we go. this doesn't seem to be the case however. certainly i can't use the interface created because of the WebGetAttribute reference :S
what is the reccomended way? i would prefer to consume my service in the same way as the other services do for consistency, so i don't want to make new (and more verbose communication) bindings and simply expose the same service over a different endpoint. similarly using WebClient / WebHttpRequest just seems a bit backward: certainly we don't have to parse the response for the other types of bindings available, why would we for this?
any suggestions? basically i want to write as little code as possible to connect the client and the server (ideally as much as normal WCF communication would take) and would prefer to communicate with a channel, since there'd be no parsing or deserializing the JSON response on my behalf.
surely this is possible? most people working on mobile applications have chosen a REST service to communicate with, seems a bit odd that microsoft's mobile solution wouldn't neatly integrate with its own server side solution! i really hope i'm just stupid and have missed something quite glaring.
I believe at this point RESTSharp is your best option.
Another REST Client library: Spring.Rest
I have a WCF Service that I want my client to be able to consume from IIS without going through a proxy. The client was consuming asmx service in vbscript using the htc behavior:
<div id="oWSInterop" style="behavior:url(webservice.htc)"></div>
oWSInterop.useService "http://localhost/WSInteroperability.asmx", "WSInteroperability"
Set response = oWSInterop.WSInteroperability.callServiceSync("BuildSingleDoc", 1002, 19499, XMLEncode(sAdditionalDetail))
So basically I just want to make this work with making as few changes as possible on the existing client. Am I forced to use a proxy (that is, a class on the client side that exposes the operations in the WCF service) when consuming a WCF service? I do understand the benefits of a proxy and am not opposed to using it for most other client implementations, but in this case I'm not sure I have the time to deal with it on the client - i just want it to work the way it has been with only the endpoint changing.
A client-side proxy class to call the service?
Yes, you definitely need that (unless you do REST-based WCF services, which you can call with a HttpClient alone) - that's where the whole WCF runtime lives and does its magic.
If you want to call up REST-based services, you can do this without any proxy whatsoever - but then you're left to do XML or JSON parsing yourself. It can be done, but it might not be such a great idea.
What's the problem with the proxy?? It's really just a small wrapper that bundles up your calls into a serialized message and sends it to the server side. No big harm, in my opinion....
What are you seeing? What makes you thank that proxy is an issue? If that is server-side code, it should use the browsers settings (WinINet) which should work fine. Perhaps the "localhost" would be an issue, though, since to the client that still means "talk to yourself" (i.e. not the server).
If that is server side you'll probably need to configure WinHTTP appropriately; in particular, to skip the proxy for local addresses. Of course, "localhost" should loop-back anyway...
I am working on an app that has several clients - Desktop, Mobile Device, Web Portal. We're moving to an SOA kind of architecture and will be using WCF.
The WCF story is great when it comes to using netTcp+transport/message security+Windows authentication (or even UsernameToken and a custom UsernameValidator provider) on the Desktop and Web Portal side.
Where it totally breaks down is on the compact framework side...the subset of WCF it supports is so limiting. I was resigned to simply using basicHttp + Username/Password in the headers all over SSL, but it seems that you cannot add headers when on the compact framework stack (no OperationContextScope) - so that leaves me with including username/password as parameters for EVERY SINGLE operation method in the service.
Please tell me I am wrong and there is a better way.
Your best bet is going to be to expose a WCF end-point that conforms to the WS-Security standards.
You should then be able to use those standards for message based security (most likely using X.509). Here's the MSDN link to get started:
Messaging in the .NET Compact Framework
An alternative solution is to pass a ticket (read: guid).
The client logs in (sends username and password). A randomly generated ticket is generated (guid again), cached on the server, and sent back to the client. This ticket is then passed back and forth instead of the username and password.
Of course, all of that is assuming you don't just want to utilize session state.
But in other words: I've had the same problem you've had. It sucks. This is how I got around it a bit so it was usable.
Anyway, another good reference is the WCF Guidance for Mobile.