I have defined a function in the ServiceContract of my WCF service as followed:
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare, UriTemplate = "/test")]
CommandResponse Test();
And on the other end, at the client app I added the WCF service via "Add service reference" in visual studio. When calling the service test function using:
var test = m_ServiceClient.Test();
I am getting an error saying:
Operation 'GetUser' of contract... specifies multiple request body parameters to be serialized ...
The GetUser() is an other function I have in the service contract (also a GET function but with parameters in the UriTemplate).
My guess is that the client is calling the function with it's parameters as it should but the request is going to the wrong UriTemplate (or with no template at all and it just jumps to some kind of default).
Any special instructions I have to follow to let the client know about the functions UriTemplates ?
I've search all over and could not find a single page that helps with this issue...
The WebInvoke/WebGet attributes are used when you expose your service via WebHttpBinding which is for consuming your WCF service in REST style. In order to access the method via SOAP add [OperationContract] attribute and expose a endpoint via basicHttpBinding.
If you would want to access the service in a REST style then you should use the HttpWebRequest class to create your request rather than adding a Add Service Reference.
For achieving both i.e accessing the service via SOAP and REST just add [OperationContract] along with the WebInvoke attribute and expose another endpoint element with basicHttpBinding
For the client to recognize the UriTemplates and pass each method to it's own Url in the format defined by the template I copied the ServiceContract Interface to the client and then created a channel to the service base url
WebChannelFactory<IServiceContract> cf = new WebChannelFactory<IServiceContract>(new Uri("http://...."));
var service = cf.CreateChannel();
The resulting 'service' is a usable interface that works directly with the web service.
Related
I have a restful service living on our company server IIS 7.5. The url is http://11.52.36.251/MessagingServices/IData.svc. I used Restsharp/Restclient to test it from client side.
When I put the url in the browser and hit "ENTER", the wsdl link was generated.
But I heard that restful service didn't have a wsdl, but why I saw it?
I checked the code inside the service, there are
public interface IData
{
[OperationContract]
[WebGet(BodyStyle=WebMessageBodyStyle.Bare,
ResponseFormat=WebMessageFormat.Json,
UriTemplate="/api")]
void GetApi();
[OperationContract]
[WebGet(BodyStyle = WebMessageBodyStyle.Bare,
RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json,
UriTemplate = "/GetIData?iId={iId}&facilityId={internalId}")]
IDTO GetIData(string iId, string internalId);
}
Is it a fake restful service or other reason?
A restful service should be able to document itself strictly through its API, or simple readable HTML document. However, any service developed in WCF will have a WSDL by default, so just because a service has a WSDL doesn't mean its not RESTful. If it truly is RESTful, the service developer should disable the mex endpoint to keep its WSDL from being published, thus assuring clients are using the service in the intended way.
I am trying to make Android consume a simple WCF webservice made by my self. Here is my WCF Service definition:
[WebInvoke(Method = "POST", ResponseFormat = WebMessageFormat.Json,
RequestFormat = WebMessageFormat.Json,
BodyStyle = WebMessageBodyStyle.Bare,
UriTemplate = "/UploadCallLog2")]
[OperationContract]
String UploadCallLog2(String number, String cached_name, String duration, String date, String line_number);
I have two questions:
1. And what should my HTTP Request Look Like? What kind of Content type should I choose when add the request header?
2. Is there the correct way to put input param in body as JSON and the webservice can auto detect the value of input parameters?
Fred
I would suggest using an MVC project for this over a WCF service.
The controller can return a JsonResult, the MVC library contains Json helper methods to serialize and deserialize the json objects into c# objects if the properties match.
Also this then allows the MVC based service to be called from any client that has support for XmlHttpRequest using ContentType as "application/json". You can use either HttpGet or HttpPost depending on your request type and security of data under SSL as well. You can also take advantage of the authentication model to secure your methods.
This just makes for a really clean implementation that doesn't have any complex server and client configurations. More information regarding similar approaches is the new Web API in MVC 4.
I am trying to send data from my RESTful client to my RESTful server. How do I pass an object which contains string, int, byte[], etc. using c# web/desktop client. I need help for client side implementation. Please guide me.
My server code like:
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "")]
void GetObject(Object obj);
You may have to use KnownTypeAttribute to specify what types that obj may be, so that the WCF DataContractSerializer can work.
I'm trying to build a C# service in .NET 3.5 that supports both SOAP - and shows the WSDL - and REST.
The SOAP service and WSDL generation was easy enough to do using the ServiceHost and a BasicHttpBinding classes. Got that working and the client was happy.
Because the SOAP calls all used simple parameters, the client developers requested a REST interface for some of the commands. So I changed the ServiceHost class to a WebServiceHost, added necessary WebInvoke and WebGet attributes, added a WebHttpBinding class, and bingo - REST and SOAP were both working out of one service. Way cool, change one interface and both REST and SOAP got the new stuff.
But one problem - the WSDL no longer gets generated. I couldn't browse to http://server/service?wsdl and get the WSDL file. Checking the MSDN docs, that appears to be behavior for a default WebServiceHost.
Question: can I override this behavior so that the WSDL could be obtained? Doesn't have to the same URL as before - it can change - but I just need to have some URL into service to get the WSDL for those SOAP developers.
When you say "added a WebHttpBinding class", it sounds like you are doing a lot of the configuration in code as opposed to in configuration files.
If this is the case, you could try moving the configuration to the configuration file. Then create 2 endpoints for the contract one REST and one SOAP, with 2 different addresses and bindings.
But one problem - the WSDL no longer
gets generated. I couldn't browse to
http://server/service?wsdl and get the
WSDL file. Checking the MSDN docs,
that appears to be behavior for a
default WebServiceHost.
Yes - that's one of the drawbacks of REST - no more WSDL, no more machine-readable service description. You need to hope the service provider gives you a usable and up to date documentation on what you can do.
There's no WSDL for REST - period. Can't be turned on or anything - it just doesn't exist.
There are some efforts under way to provide something similar - called WADL (Web Application Description Language), but as far as I know, it's still far from an established standard by any means. Also see: Do we need WADL?
Circa, 2007, WSDL v2.0 is supposed to be able to describe RESTful services. I have found that with WCF in .Net v4.0, that the WDSL generated from a purely RESTful service is invalid (WSDL v1.0?).
I created a similar project that exposes both SOAP and RESTful endpoints, and enabled this by, as you did, modifying the interface as such:
// Get all Categories - complex object response
[OperationContract] // categories
[WebGet(BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "GetAllCategories")]
CategoryCollection GetAllCategories(); // SubSonic object
[OperationContract] // categories - respond with a JSON object
[WebGet(ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "GetAllCategories.JSON")]
CategoryCollection GetAllCategoriesJSON(); // SubSonic object
One caveat to this is that all input parameters now must be of type string for all SOAP requests.
Any way of getting around this?
I currently have a WCF service to consume a remote REST service with the following:
[ServiceContract]
[XmlSerializerFormat]
public interface IMyApi
{
[OperationContract]
[WebGet(
ResponseFormat = WebMessage.Xml,
UriTemplate = "RemoteServicePage.jsp")]
MyNewClass Send();
}
The nice part about this is the XmlSerializerFormat attribute. Automatically deserializes a response into the return type of the method(ie, POX response => MyNewClass).
I've been unsuccessful, however, in finding any samples of the reverse. I'd like to post a POX request to a given service. I'm curious if there's a similar way to pass an object to a WCF service which in turn makes the post request to the target.
Any thoughts are greatly appreciated.
UPDATE
Just a clarification of the question:
Is it possible to post an object to a web service via WCF(which handles the serialization)?
UPDATE
I believe Steve touched on what I believe is the right direction below with using the WebInvoke method and attribute RequestFormat to achieve what I'm looking for. I guess I want to point out I'm not hosting a web service that allows for posting, but rather trying to post to an external web service(ie, a remote *.jsp) using WCF.
WCF allows for easy consumption and access of external web services and this is something I'm familiar with. I've never attempted to post a stream or object to an external source however(posting via UriTemplate is straightforward).
I don't understand. Why not just use HttpWebRequest? One of the benefits of doing REST over HTTP is that you get to use standard HTTP libraries. Doing a POST with HttpWebRequest is relatively trivial. Why do you need WCF? If you want to serialize an object into your POST body, then you can do that with either the DataContractSerializer or with the XmlSerializer.
If you really don't like that option, then look at the new Microsoft.Http.HttpClient class that is in the WCF Rest Starter Kit Preview 2. It is a very nice client library and despite its name and packaging, it does not even have a dependency on WCF!
This answer is based on your second update. I only say this because your initial statement of "I currently have a WCF service to consume a remote REST service" makes no sense. You cannot declaratively define a remote interface that you want to consume. The term WebInvoke is not what you are thinking, it is simply a catch all attribute for handing non GET requests. WebGet and WebInvoke both handing incoming requests.
If you want to consume a remote "REST" interface then you need to use HttpWebRequest or the new HttpClient class.
I don't think you understand the meaning of XmlSerializerFormat. It means that the XML Serializer should be used instead of the Data Contract Serializer. Both will serialize to XML.
Use the RequestFormat attribute. For JSON, this would be
[WebInvoke(Method = "POST",
BodyStyle = WebMessageBodyStyle.WrappedRequest,
ResponseFormat = WebMessageFormat.Json,
RequestFormat = WebMessageFormat.Json)]
Good luck