How can I POST (as XML) an object to my ApiController using RestSharp? - serialization

I have an ASP.NET MVC4 website implementing a REST API, which I'm consuming from a client application. My ApiController methods take and return complex objects, as XML.
I recently discovered RestSharp, and have begun moving my client project over to that. However, I'm having real problems with it. It seems to almost work - it's so close that I can almost taste success - but I just can't get it to work 100%.
The objects I'm passing across the wire look something like this:
// The object I'm passing across the wire
public class Example
{
bool IsActive { get; set; }
string Name { get; set; }
}
My ApiController method looks like this:
// My ApiController method
public HttpResponseMessage PostExample(Example example)
{
if (ModelState.IsValid)
{
db.Examples.Add(example);
db.SaveChanges();
HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.Created, example);
return response;
}
else
{
return Request.CreateResponse(HttpStatusCode.BadRequest);
}
}
The problem occurs when I try to POST an object to my website, like this:
var example = new Example () { IsActive = true, Name = "foo" };
var request = new RestSharp.RestRequest("/api/example", RestSharp.Method.POST);
request.AddBody(example, XmlNamespace);
var client = new RestClient();
client.BaseUrl = "foo.com";
var response = client.Execute<Example>(request);
The code above does hit the PostExample method in my ApiController, and it has an Example object as the parameter. However the values of the properties of the Example object are not the same as I passed to the Execute method! In one case, the IsActive member was false instead of true, although I also saw a case where the Name member was null where it should have had a value.
I did some investigation using Fiddler, and it seems that the correct values are being created in the XML that RestSharp generates. However, the XML is not quite in the same format that the web server emits when doing a GET. The differences are subtle, but seem to make the difference between it working and not working. The framework at the web server end seems to be sensitive to these formatting differences, and is mis-interpreting the XML as a result.
Here's the XML I get from RestSharp:
<Example xmlns="http://schemas.datacontract.org/2004/07/ExampleNamespace">
<Name>foo</Name>
<IsActive>true</IsActive>
</Example>
This is what I get when doing a GET on the webserver (or when serializing using the DataContractSerializer, which is what I was previously doing):
<Example xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/ExampleNamespace">
<IsActive>true</IsActive>
<Name>foo</Name>
</TagDto>
The RestSharp version has the following differences from the DataContractSerializer's version:
Fields are in a different order
RestSharp doesn't include the extra namespace XMLSchema-instance namespace
DataContractSerializer doesn't include any spaces or line-breaks (I added those above for readability)
I'm surprised that any of those make much of a difference, but clearly they do. Note also that until I added an explicit namespace in the AddBody call, this was missing in the generated XML (obviously), and the Example object passed into my ApiController was null.
Anyway, I noticed that RestSharp allows you to override the serializer, and provides a way to use the .NET XML serializer. I tried using that (to no avail).
This is what I added before the call to AddBody:
request.XmlSerializer = new RestSharp.Serializers.DotNetXmlSerializer(XmlNamespace);
..and this is what I get out:
<?xml version="1.0" encoding="utf-8"?>
<Example>
<Name>foo</Name>
<IsActive>true</IsActive>
</Example>
This is clearly no good, not least because it starts with an XML declaration, which I imagine would cause problems. There's no way to turn that off, because the RestSharp derived class provides no way to do so. Also, there's no namespace - and I can't get one to appear in the output no matter how I try to set the namespace in RestSharp (in the constructor for the DotNetXmlSerializer, by setting the Namespace member, or by passing in a namespace to AddBody). To my eyes, this class is nothing more than a trap.
It looks like my only option is to create my own serializer class and use the DataContractSerializer internally. Is that right, or am I missing something?
(BTW, I can set the RequestFormat of the request to JSON and it just works - but I'd still like to know how to get this working with XML).

I've had some issues with the AddBody calls not properly serializing JSON values, so there might be some similarity to your problem. Instead of AddBody, you could try:
request.AddParameter("text/xml", xmlAsString, ParameterType.RequestBody);
If that works, you could look to see about changing the second parameter to be the xml object and see if the serializer does what you want.
The other option could be the XmlMediaTypeFormatter.ReadFromStreamAsync isn't properly picking up a proper serializer; you could try overriding that function.

The issue above is because WebAPI is using the DataContractSerializer (as opposed to the XmlSerializer which is what you're after). To switch this around modify Global.asax as follows.
var xml = GlobalConfiguration.Configuration.Formatters.XmlFormatter;
xml.UseXmlSerializer = true;
However, I suggest you use the RESTSharp formatters for WebAPI (instead of using the .Net formatters). This is particularly useful if you're DTO's have circular references (the .net fx serializers don't handle this too gracefully).
In Global.asax, modify the formatters by putting in
GlobalConfiguration.Configuration.Formatters.XmlFormatter = //RestSharp XML serializer here
A quick overview of serialization in WebAPI is here and worth a browse

Related

WCF generated proxy throws InvalidOperationException due to multiple types with same name in WSDL

I'm using Visual Studio 2013 to generate a WCF service proxy from this WSDL file. However, as soon as I try to call the setSalesItemsV3 method, WCF throws an InvalidOperationException from deep in System.Xml.dll.
This sample project demonstrates the problem: https://github.com/jennings/WsdlDuplicateNameProblem
This is the inner exception:
Message: The top XML element 'start' from namespace '' references distinct types WsdlDuplicateName.SalesItemService.hsSimpleDate and System.DateTime. Use XML attributes to specify another XML name or namespace for the element or types.
I'm no expert at reading WSDL, but I've looked at it and the only sections that reference the name "start" are a few <wsdl:part> elements with name="start":
<wsdl:message name="setSalesItems">
<wsdl:part name="start" type="xsd:dateTime"></wsdl:part>
</wsdl:message>
<wsdl:message name="setSalesItemsV3">
<wsdl:part name="start" type="tns:hsSimpleDate"></wsdl:part>
</wsdl:message>
But, the parts are in completely different messages, so I don't see why there should be any confusion. I've run the WSDL file through several online WSDL validators and they seem to be okay with it.
Below is the only code in the project necessary to reproduce the problem (besides the generated proxy).
class Program
{
static void Main(string[] args)
{
SalesServiceClient client = new SalesServiceClient();
var date = ToSimpleDate(new DateTime());
// throws InvalidOperationException
// Message == "There was an error reflecting 'start'."
client.setSalesItemsV3(1, 1, null, date, date);
}
static hsSimpleDate ToSimpleDate(DateTime time)
{
return new hsSimpleDate
{
year = time.Year,
month = time.Month,
day = time.Day,
};
}
}
To demonstrate the problem let’s take a look into generated Reference.cs:
public partial class getSalesItemsV3 {
// skipped
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="", Order=2)]
public WsdlDuplicateName.SalesItemService.hsSimpleDate start;
// skipped
}
public partial class setSalesItems {
// skipped
[System.ServiceModel.MessageBodyMemberAttribute(Namespace="", Order=3)]
public System.DateTime start;
// skipped
}
Please note that these elements have the same name (start) and the same namespace declared by the MessageBodyMember attribute ("", empty namespace). This cause "The top XML element 'start' from namespace '' references distinct types" serializer exception.
If we have this option:
(b) the changes I can make to the generated proxies to make the
serializer happy
... we can set namespaces for elements start, end and return (they all cause troubles) manually. I did it by myself and put the result here. You can paste it into your Reference.cs and serializer exception will gone.
But it seems that the root cause of your issue is that this service (http://services.hotschedules.com/api/services/SalesService?wsdl) is intended to be used through WebServices (and this problem is some kind of incompatibilities).
If you add reference to this server as a Web Reference (Add -> Service Reference... -> Advanced... -> Add Web Reference...) and write the same web method call, no problems with serialization will occur. Actually, in my case I received another kind of server exceptions in my test example, but it will solve your immediate serialization problem.
The mirror copy of your code, but using Web Service Reference (and not requires any changes in generated files) can be found here.
Hope this will help.
UPDATE: To found what is actually cause this problem we need to deep delve in XmlReflectionImporter source code. First, our WSDL using XSD schemas to define namespaces: http://www.w3.org/2001/XMLSchema for xsd and http://services.hotschedules.com/api/services/SalesService for tns. XmlReflectionImporter using NameTable (this is a wrapper for Hashtable) to store "accessors". Accessor is a pair of Namespace and Name.
Let's see source code that throws exception:
private Accessor ReconcileAccessor(Accessor accessor, NameTable accessors)
{
// initial check skipped
// look for accessor by name and namespace, add to accessors hash if not found and return
Accessor accessor1 = (Accessor) accessors[accessor.Name, accessor.Namespace];
if (accessor1 == null)
{
accessor.IsTopLevelInSchema = true;
accessors.Add(accessor.Name, accessor.Namespace, (object) accessor);
return accessor;
}
// accessor ("start" in our case) found!
// check if mappings is the same and return accessor. This is not our case, we have two accessors with the same name but different mappings (despite that this mappings is have the same type)!
if (accessor1.Mapping == accessor.Mapping)
return accessor1;
// next I skipped some reconciliations for MembersMapping and ArrayMapping. Please note that it performed by types, for example:
// if (accessor.Mapping is ArrayMapping) { /* some logic */}
// Our mapping is not MembersMapping or ArrayMapping and we finally got there:
throw new InvalidOperationException(Res.GetString("XmlCannotReconcileAccessor", (object) accessor.Name, (object) accessor.Namespace, (object) XmlReflectionImporter.GetMappingName((Mapping) accessor1.Mapping), (object) XmlReflectionImporter.GetMappingName((Mapping) accessor.Mapping)));
// Resource definition is: XmlCannotReconcileAccessor=The top XML element '{0}' from namespace '{1}' references distinct types {2} and {3}. Use XML attributes to specify another XML name or namespace for the element or types.
// using this resource template you can see that string representations of mappings are "WsdlDuplicateName.SalesItemService.hsSimpleDate" and "System.DateTime".
}
So, the main reconciliation logic is we can't have two accessors with the same name but different namespaces! There're may be some exceptions for MembersMapping and ArrayMapping types, but it is not our case.
I believe that this is some kind of a bug. The WSDL is correct and will pass validation, but due to this generic implementation of ReconcileAccessor from XmlReflectionImporter class we got an exception. Not sure if this is exact problem of XmlReflectionImporter, or may be there's another problem on a higher abstract layer. And, source generated by "Web Reference" is not using XmlReflectionImporter.
Another thing is worth to mention: generator puts a Namespace="" value for MessageBodyMemberAttribute, what is effectively break the reconciliation process. So, I believe there's some inconsistency or incompatibility.
Your problem might be how you are using the WSDL. Where I work we have older services that requires us to use wsdl.exe to generate the class files from the WSDL. We also use SoapUI to test our services. Without changing any of the WSDL or generated code I can make a request to that system.
Fiddler captures:
Outbound
POST http://services.hotschedules.com/api/services/SalesService HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.18444)
VsDebuggerCausalityData: uIDPo7vfNRAHy8VFtfrdjickfDQAAAAAVvkpSjtKpEyy02P7sVr8C51Xoz163FNKvwhRT+6uA+wACQAA
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Host: services.hotschedules.com
Content-Length: 536
Expect: 100-continue
Proxy-Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><setSalesItemsV3 xmlns="http://services.hotschedules.com/api/services/SalesService"><concept xmlns="">1</concept><storeNum xmlns="">1</storeNum><start xmlns=""><day>1</day><month>1</month><year>1</year></start><end xmlns=""><day>1</day><month>1</month><year>1</year></end></setSalesItemsV3></soap:Body></soap:Envelope>
Inbound
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Content-Length: 366
Date: Thu, 26 Mar 2015 16:51:22 GMT
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode xmlns:ns1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:InvalidSecurityToken</faultcode><faultstring>Error in SecurityHeader: An invalid security token was provided</faultstring></soap:Fault></soap:Body></soap:Envelope>
I received a 500 error from the system for not supplying security.
I see a few options:
use "add web reference" instead of "add service reference". I have verified it works. this will fallback into classic asp.net service proxy which is not as shiny as wcf but will do the work.
since there are only 6 methods (some seem dummy) you could import the wsdl 6 times into 6 different proxies (probably less). each time chnage the wsdl to contain only one operation (just delete the otehr operation tags, don't bother with messages/schema).
change the parameter names in the wsdl (start --> start1, start2...) and then in runtime build some message inspector that changes back (start1,start2-->start).
(not tested) I beleive you can refactor the WSDL such that instead of part elements each message will have one part called "parameter" which will direct to a wrapper xsd type with all of the original parts. you will build one wrapper per message. you can configure wcf to treat this as bare parameters and not emit the dummy wrapper element so on the wire it looks the same.
of course if you are in position to change the server that is best.
Every option has its pros and cons. Some will have a runtime overhead (#3) and some will complicate the design time. It also depends if you expect this WSDL to change and you will need to reimport it many times.

wsdl2java code generation for lists of custom objects

I would like to know if the tool "wsdl2java" (Axis2) is able to generate stubs that support getting list of custom ojects.
For instance, if I have a WS that have the following method:
public List<Device> getDevices(){
//...
}
Where Device is a custom class...
This tool can do that?
I changed the return data type of my Web Service to an array because of that:
http://www.ibm.com/developerworks/webservices/library/ws-tip-coding/index.html
And I had to do some changes (some namespaces) to the generated stub (I used ADB)...
I changed that because it was giving me an ADBException: Unexpected subelement ...

JAX-RS return a Map<String,String>

I want to retrieve a Map from a using JAX-RS (text/xml)
#GET
public Map<String,String> getMap(){
}
but I am getting the error below:
0000001e FlushResultHa E org.apache.wink.server.internal.handlers.FlushResultHandler handleResponse The system could not find a javax.ws.rs.ext.MessageBodyWriter or a DataSourceProvider class for the java.util.HashMap type and application/x-ms-application mediaType. Ensure that a javax.ws.rs.ext.MessageBodyWriter exists in the JAX-RS application for the type and media type specified.
[10:43:52:885 IST 07/02/12] 0000001e RequestProces I org.apache.wink.server.internal.RequestProcessor logException The following error occurred during the invocation of the handlers chain: WebApplicationException (500 - Internal Server Error) with message 'null' while processing GET request sent to http://localhost:9080/jaxrs_module/echo/upload/getSiteNames
The solution I choose is to wrap a Map and use it for the return param.
#XmlRootElement
public class JaxrsMapWrapper {
private Map<String,String> map;
public JaxrsMapWrapper(){
}
public void setMap(Map<String,String> map) {
this.map = map;
}
public Map<String,String> getMap() {
return map;
}
}
and the method signature will go like this
#GET
public JaxrsMapWrapper getMap()
Your problem is that the default serialization strategy (use JAXB) means that you can't serialize that map directly. There are two main ways to deal with this.
Write an XmlAdaptor
There are a number of questions on this on SO but the nicest explanation I've seen so far is on the CXF users mailing list from a few years ago. The one tricky bit (since you don't want an extra wrapper element) is that once you've got yourself a type adaptor, you've got to install it using a package-level annotation (on the right package, which might take some effort to figure out). Those are relatively exotic.
Write a custom MessageBodyWriter
It might well be easier to write your own code to do the serialization. To do this, you implement javax.ws.rs.ext.MessageBodyWriter and tag it with #Provider (assuming that you are using an engine that uses that to manage registration; not all do for complex reasons that don't matter too much here). This will let you produce exactly the document you want from any arbitrary type at a cost of more complexity when writing (but at least you won't be having complex JAXB problems). There are many ways to actually generate XML, with which ones to choose between depending on the data to be serialized
Note that if you were streaming the data out rather than assembling everything in memory, you'd have to implement this interface.
Using CXF 2.4.2, it supports returning Map from the api. I use jackson-jaxrs 1.9.6 for serialization.
#Path("participation")
#Consumes({"application/json"})
#Produces({"application/json"})
public interface SurveyParticipationApi {
#GET
#Path("appParameters")
Map<String,String> getAppParameters();
....
}
With CXF 2.7.x use
WebClient.postCollection(Object collection, Class<T> memberClass, Class<T> responseClass)
,like this in your rest client code.
(Map<String, Region>) client.postCollection(regionCodes, String.class,Map.class);
for other collections use WebClient.postAndGetCollection().

Consume WCF Data service in client application throws error

I am working on WCF Data service which imported stored procedure, as below.
[WebGet]
public List<GetMTSearchResultTest_Result> GettMTSearchResultTest()
{
MediaMarketResearch_PRODEntities ent = new MediaMarketResearch_PRODEntities();
return ent.GetMTSearchResultTest().ToList();
}
when i consuming this in my client application it says error as "The closed type MMRClient.MMRServiceReference.GetMTSearchResultTest_Result does not have a corresponding element settable property."
I am getting this error while bind to the grid view as below.
DataServiceContext context = new DataServiceContext(new Uri("http://localhost:4131/MMRDataService.svc/"));
IEnumerable<GetMTSearchResultTest_Result> empResult = context.Execute<GetMTSearchResultTest_Result>(new Uri("http://localhost:4131/MMRDataService.svc/GettMTSearchResultTest"));
GridView1.DataSource = empResult;
GridView1.DataBind();
Note: I imported this stored proc as complex type.
Please advice me on this.
Regards,
Jaydeep
I think this link may help you (see the selected answer).
Essentially, what the solution may be is to create a partial class for GetMTSearchResultTest_Result and decorate it with a DataServiceKey attribute, providing a non-nullable column that acts as a primary key (although I don't think it has to be unique).
So your partial class would look something like:
[DataServiceKey("YourKeyColumnName")]
public partial class GetMTSearchResultTest_Result {
}
If you're just doing reads, I don't think you'll need any implementation.
Hopefully this works. Let me know if there are issues/questions and I'll update accordingly.
You can always make a new service reference to a non data service. That is to a normal WCF service. You can simply have a [ContractOperation] returning a list of the troubled "complex types" and that's it.
This way you would have two services the original data service and a new normal WCF service. But this shouldn't be such an issue. You don't have to make the troubled "complex type" as a Entity.

Efficiency of deserialization vs. XmlReader

I'm working with a complicated xml schema, for which I have created a class structure using xsd.exe (with some effort). I can now reliably deserialize the xml into the generated class structure. For example, consider the following xml from the web service:
<ODM FileType="Snapshot" CreationDateTime="2009-10-09T19:58:46.5967434Z" ODMVersion="1.3.0" SourceSystem="XXX" SourceSystemVersion="999">
<Study OID="2">
<GlobalVariables>
<StudyName>Test1</StudyName>
<StudyDescription/>
<ProtocolName>Test0001</ProtocolName>
</GlobalVariables>
<MetaDataVersion OID="1" Name="Base Version" Description=""/>
<MetaDataVersion OID="2" Name="Test0001" Description=""/>
<MetaDataVersion OID="3" Name="Test0002" Description=""/>
</Study>
</ODM>
I can deserialize the xml as follows:
public ODMcomplexTypeDefinitionStudy GetStudy(string studyId)
{
ODMcomplexTypeDefinitionStudy study = null;
ODM odm = Deserialize<ODM>(Service.GetStudy(studyId));
if (odm.Study.Length > 0)
study = odm.Study[0];
return study;
}
Service.GetStudy() returns an HTTPResponse stream from the web service. And Deserialize() is a helper method that deserializes the stream into the object type T.
My question is this: is it more efficient to let the deserialization process create the entire class structure and deserialize the xml, or is it more efficient to grab only the xml of interest and deserialize that xml. For example, I could replace the above code with:
public ODMcomplexTypeDefinitionStudy GetStudy(string studyId)
{
ODMcomplexTypeDefinitionStudy study = null;
using (XmlReader reader = XmlReader.Create(Service.GetStudy(studyId)))
{
XDocument xdoc = XDocument.Load(reader);
XNamespace odmns = xdoc.Root.Name.Namespace;
XElement elStudy = xdoc.Root.Element(odmns + "Study");
study = Deserialize<ODMcomplexTypeDefinitionStudy>(elStudy.ToString());
}
return study;
}
I suspect that the first approach is preferred -- there is a lot of dom manipulation going on in the second example, and the deserialization process must have optimizations; however, what happens when the xml grows dramatically? Let's say the source returns 1 MB of xml and I'm really only interested in a very small component of that xml. Should I let the deserialzation process fill up the containing ODM class with all it's arrays and properties of child nodes? Or just go get the child node as in the second example!!??
Not sure this helps, but here's a summary image of the dilemma:
Brett,
Later versions of .net will build custom serializer assemblies. Click on project properties -> build and look for "Generate serialization assemblies" and change to On. The XML deserializer will use these assemblies which are customized to the classes in your project. They are much faster and less resource intensive since reflection is not involved.
I would go this route so that if you class changes you will not have to worry about serialization issues. Performance should not be an issue.
I recommend that you not preoptimize. If you have your code working, then use it as it is. Go on to work on some code that is not finished, or which does not work.
Later, if you find you have a performance problem in that area, you can explore performance.