Anonymous objects are automatically serialized as expected when returned from controller action.
When returning class instance, http response contains only empty json body, why? Where is this documented?
Ok, I forgot to add default { get; set; } to the properties, this seems to be compulsory for the json serializer.
Related
I have written a custom serializer and attached it to my RestClient. I am trying to also implement a custom deserializer as well. I noticed in my code that the serializer gets called when i added it to my client like so :RestClient Client = new RestClient(options).UseSerializer<CustomJsonSerializer>();
However, I am not sure what code to add to point to my custom deserializer and where to add it.
I am trying to call a method that essentially hijack's the response content, changes the string, and then sends the modified string back as the new response content to then be deserialized.
Where would i add the code to call my custom deserializer? What would the code snippet look like? And is it possible to even alter the response.content before the deserialization happens? And if so, how do i implement that?
The UseSerializer<T> expects T to be IRestSerializer, which has properties for ISerializer and IDeserializer. The Deserializer property needs to return your custom deserializer.
public interface IRestSerializer {
ISerializer Serializer { get; }
IDeserializer Deserializer { get; }
...
I am using Asp.Net Core 2.0 and web api to build a rest service. All works fine except for HTTPPost.
[HttpPost("LoginUser")]
public IActionResult LoginUser(LoginUser loginUser)
{
return Ok(loginUser);
}
loginUser is always null. I am testing with fiddler and my route is http://localhost:53250/api/User/LoginUser
and the body is
{"EmailAddress":"xx#xx.com","Password":"123456789"}
Fiddler hits the link just fine, but payload is always null.
I have also tried
[HttpPost("LoginUser")]
public IActionResult LoginUser([FromBody] LoginUser loginUser)
{
return Ok(loginUser);
}
In this case, it doesn't hit the function.
This is the LoginUser definition:
public class LoginUser
{
public string EmailAddress { get; set; }
public string Password { get; set; }
}
Any Ideas?
Your action should be:
[Route("api/[controller]")]
public class UserController : Controller
{
[HttpPost("LoginUser")]
public IActionResult LoginUser([FromBody] LoginUser loginUser)
{
return Ok(loginUser);
}
}
See, [HttpPost("LoginUser")] affects only route and doesn't relate to LoginUser object type.
Update: you need [FromBody] as ASP.NET Core model binding by default looks into [FromForm] binding source. And [FromBody] attribute indicates that you want to bind a parameter to data in the request body.
Update 2: you also should add Content-Type: application/json header to request. ASP.NET Core selects input formatters based on the this header.
Update 3: if you really need to get body data as raw string, look into ASP.NET Core MVC : How to get raw JSON bound to a string without a type?. It suggests using [FromBody] dynamic data
JSON parsing is case sensitive. Your JSON is in the wrong case.
Should be: {"EmailAddress":"xx#xx.com","Password":"123456789"}.
Issue has been solved. When I added my UserController, I did so as a class and derived from controller. I deleted it and added it as a new item and picked web api core controller. Now all is working just fine. Thanks for your help.
If you have properties in your request model that are set to {get;
private set;}, the values will not get populated. Make them public by removing private. Also constructors
aren't utilized.
If you're reading plain text from the body, see if [FromForm]
works.
I am developing a wcf application which is taking c# request model as an input and returning complex response c# model after populating data in it from database. I am using SOAP UI client tool to test my service.
Earlier i had decorated my contract with XmlSerializerFormat attribute and after submitting request i was able to get the response in Result tab of SOAP UI tool. Below is the code snippet of it :
[ServiceContract]
[XmlSerializerFormat]
public interface IService1
{
[OperationContract]
Employee GetData(Employee value);
}
[DataContract]
public class Employee
{
[DataMember]
public int Id { get; set; }
[DataMember]
public string Name { get; set; }
public string Address { get; set; }
}
But now due to some reasons i have removed XmlSerializerFormat attribute from contract and i want default serializer to take care of it. But when i am submitting the request from client , my response model is populating with results but Response tab of SOAP UI shows empty response.
During Response model population when i am removing certain properties from response model, i am able to see result in response tab of SOAP UI tool.
Is Default serializer in facing some issues while serializing some of property of my model. Any other attribute apart from XmlSerializerFormat ?
Please let me know where i am lacking or is there any alternative of XmlSerializerFormat attribute.
Thnx in Advance
Try adding DataContract attribute to the Employee on the class level and DataMember attribute to its properties that you want to be serialized. If it has complex property types of its own they also may need to be decorated similarly. Default serializer in WCF is DataContract serializer FYI.
I'm bit confused with how MessageContract Attribute works in WCF.
When I put the MessageContract the proxy shows two parameters instead of 1.
e.g.
GetResultResponse GetOperation(GetResultRequest request)
[MessageContract]
public class GetResultRequest
{
[MessageHeader]
public Header Header { get; set; }
[MessageBodyMember]
public List<Person> PersonList { get; set; }
}
The proxy generates this method signature:
GetOperation(ref Header, List<Person> personList)
When I remove MEssageContract Attributes:
Proxy Generates correct signatures:
GetOperation(GetResultRequest request)
Could anyone please confirm if this is the expected behavour?
That is default behavior. When you generate proxy it doesn't create message contracts by default. You can turn this on in advanced configuration in Add Service reference (by checking Always generate message contracts) or by /messageContract switch in svcutil. Once you turn it on you will get methods with single message contract parameter as you have on the service.
Unless you have the specific requirement to mark the header with the MessageHeader attribute, try to change the class attribute to Datacontract and your properties to DataMember attributes and see if the behaviour changes. As far as I know, unless you implement a custom serializer you cannot influence how svcutil will create your proxy.
I'm trying to take a datacontract object that I received on the server, do some manipulation on it and then return an upcasted version of it however it doesn't seem to be working. I can get it to work by using the KnownType or ServiceKnownType attributes, but I don't want to roundtrip all of the data. Below is an example:
[DataContract]
public class MyBaseObject
{
[DataMember]
public int Id { get; set; }
}
[DataContract]
public class MyDerivedObject : MyBaseObject
{
[DataMember]
public string Name { get; set; }
}
[ServiceContract(Namespace = "http://My.Web.Service")]
public interface IServiceProvider
{
[OperationContract]
List<MyBaseObject> SaveMyObjects(List<MyDerivedObject> myDerivedObjects);
}
public class ServiceProvider : IServiceProvider
{
public List<MyBaseObject> SaveMyObjects(List<MyDerivedObject> myDerivedObjects)
{
... do some work ...
myDerivedObjects[0].Id = 123;
myDerivedObjects[1].Id = 456;
myDerivedObjects[2].Id = 789;
... do some work ...
return myDerivedObjects.Cast<MyBaseObject>().ToList();
}
}
Anybody have any ideas how to get this to work without having to recreate new objects or using the KnownType attributes?
I think that your problem is that you are trying to send over a generic list.
It will work if you encapsulate the list in an object. That is create an object with a single public property which is the generic list.
You also need to make sure that all classes that are not used directly in the contract are marked as serializable.
If you want to return the derived objects then there will always be a round trip because the client and the service are separate. In order for the client to update its own list of MyBaseObjects it has to deserialize the list of MyDerivedObjects that came from the server.
The use of KnownType and/or ServiceKnownType is needed because this leads to the addition of that type information into WSDL, which is in turn used by the client to deserialize the messages to the correct type.
For starters, a useful tool for testing the scenario you've described: http://www.wcfstorm.com
You might try creating a DataContractSurrogate (IDataContractSurrogate) and returning your base type for the call to GetDataContractType. I'm not really sure that's how it was intended to be used so you still may be better of with "the extra work", but maybe I don't understand the scope of that extra work.
One of the problems with WCF (and .net remoting) is that it they tries to make “message passing” look like method calls.
This fall down when you try to use too many “oop” type designs.
The fact that the messages are
represented by .net classes, does not
make all of their behaviour like .net
class.
See this, and this, for more on the problem of Leaking Abstraction.
So you need to start thinking about message passing not object when designing your WCF interfaces, or you will hit lots of problems like this.