Web API response formatting
Folks, what is the recommended way of letting the caller choose the format of the response? I have a method that can return plain text or XML, so how does the caller choose the one they want? I could have a format= parameter on the method call (Rackspace do that), or is it better to inspect the Accept header and obey it? Or something else? Greg K
Re: Web API response formatting
Accept header is the norm On 20 January 2014 15:03, Greg Keogh g...@mira.net wrote: Folks, what is the recommended way of letting the caller choose the format of the response? I have a method that can return plain text or XML, so how does the caller choose the one they want? I could have a format= parameter on the method call (Rackspace do that), or is it better to inspect the Accept header and obey it? Or something else? Greg K
Re: Web API response formatting
In WCF you use automaticFormatSelectionEnabled=true/false to tell it to parse the header to work out what type of response to send back. I'm not sure whether it is the same in WebAPI. It seems a bit ugly to do via a querystring parameter. From: Greg Keogh g...@mira.net To: ozDotNet ozdotnet@ozdotnet.com Sent: Monday, 20 January 2014 3:03 PM Subject: Web API response formatting Folks, what is the recommended way of letting the caller choose the format of the response? I have a method that can return plain text or XML, so how does the caller choose the one they want? I could have a format= parameter on the method call (Rackspace do that), or is it better to inspect the Accept header and obey it? Or something else? Greg K
Re: Web API response formatting
Chaps, after some doodling around I see I can get the Accept values
straight out of the Request in the controller's code. That does now seem to
be the logical way of choosing the response format.
More confusion though ... I tried to write a controller method that
returned either plain text or XML, but the samples I've found return
different types. One does this:
public HttpActionResult Sample1()
return Ok(hello);
public HttpResponseMessage Sample2()
return new HttpResponseMessage() { Content = new StringContent(hello) };
On 20 January 2014 13:12, Dave Walker rangitat...@gmail.com wrote:
Accept header is the norm
On 20 January 2014 15:03, Greg Keogh g...@mira.net wrote:
Folks, what is the recommended way of letting the caller choose the
format of the response? I have a method that can return plain text or XML,
so how does the caller choose the one they want?
I could have a format= parameter on the method call (Rackspace do that),
or is it better to inspect the Accept header and obey it? Or something else?
Greg K
Re: Web API response formatting
Please ignore previous message as I hit Send instead of Save (bloody Gmail
interface!). Here's the correct message:
Chaps, after some doodling around I see I can get the Accept values
straight out of the Request in the controller's code. That does now seem to
be the logical way of choosing the response format.
More confusion though ... I tried to write a controller method that
returned either plain text or XML, but the samples I've found return
different types. Here are the two samples:
public HttpActionResult Sample1()
return Ok(hello);
public HttpResponseMessage Sample2()
return new HttpResponseMessage() { Content = new StringContent(hello) };
The firsts returns Stringhello/String and the second returns the plain
text hello. But they're different return types and I can't figure out how
get one method to return Xml or text. Anyone know how. I'm still searching.
Greg K
Re: Web API response formatting
Greg, let the web API deal with the formatting. Your controller should
ideally just return an object which will be formatted according to the
request.
(apologies for brevity, I am playing mini golf with my son)
Try it in Fiddler and you can see how changing the request will change the
output. If you hard code the response type you are introducing unnecessary
coupling snd potential future headaches.
Sent from my flux capacitor. Please excuse brevity and any odd autocorrect
errors.
On 20/01/2014 1:54 PM, Greg Keogh g...@mira.net wrote:
Please ignore previous message as I hit Send instead of Save (bloody Gmail
interface!). Here's the correct message:
Chaps, after some doodling around I see I can get the Accept values
straight out of the Request in the controller's code. That does now seem to
be the logical way of choosing the response format.
More confusion though ... I tried to write a controller method that
returned either plain text or XML, but the samples I've found return
different types. Here are the two samples:
public HttpActionResult Sample1()
return Ok(hello);
public HttpResponseMessage Sample2()
return new HttpResponseMessage() { Content = new StringContent(hello) };
The firsts returns Stringhello/String and the second returns the plain
text hello. But they're different return types and I can't figure out how
get one method to return Xml or text. Anyone know how. I'm still searching.
Greg K
Re: Web API response formatting
From my limited reading on this I think you will struggle to remove the
xmlns, the rationale being that without a namespace the xml is not valid.
While technically true, it is also annoying.
Personally I have a strong preference for JSON these days and use it
whenever I can... simple, ubiquitous and hardly any rules to conform to.
YMMV.
Cheers
Dave
Sent from my flux capacitor. Please excuse brevity and any odd autocorrect
errors.
On 20/01/2014 3:03 PM, Greg Keogh g...@mira.net wrote:
I can confirm that WebAPI does as you say and it looks for a formatter
that matches the Accept header ... To make things easier and consistent for
everyone I have abandoned the idea of returning plain text in some methods,
I will always return an XML serialised class no matter how small the data
might be. This is easier to document and the client will probably
appreciate it. So the confusion about choosing text or xml will go away.
I'll leave my text formatter there as a stub just in case someone wants csv
formatting or similar later.
I notice that if my controller method returns string then the xml
formatter sends back Stringhello/String and Accept text/plain returns
hello, which makes sense. If I try to get a class back as text it ignores
me and I get XML anyway, which also makes sense.
My task now is to remove the xmlns= clutter from the xml root.
Part of my learners confusion is the large numbers of return types that
are possible from controller methods, some not even in the same class
hierarchy.
Greg K
On 20 January 2014 14:31, David Burstin david.burs...@gmail.com wrote:
Greg, let the web API deal with the formatting. Your controller should
ideally just return an object which will be formatted according to the
request.
(apologies for brevity, I am playing mini golf with my son)
Try it in Fiddler and you can see how changing the request will change
the output. If you hard code the response type you are introducing
unnecessary coupling snd potential future headaches.
Sent from my flux capacitor. Please excuse brevity and any odd
autocorrect errors.
On 20/01/2014 1:54 PM, Greg Keogh g...@mira.net wrote:
Please ignore previous message as I hit Send instead of Save (bloody
Gmail interface!). Here's the correct message:
Chaps, after some doodling around I see I can get the Accept values
straight out of the Request in the controller's code. That does now seem to
be the logical way of choosing the response format.
More confusion though ... I tried to write a controller method that
returned either plain text or XML, but the samples I've found return
different types. Here are the two samples:
public HttpActionResult Sample1()
return Ok(hello);
public HttpResponseMessage Sample2()
return new HttpResponseMessage() { Content = new StringContent(hello)
};
The firsts returns Stringhello/String and the second returns the
plain text hello. But they're different return types and I can't figure
out how get one method to return Xml or text. Anyone know how. I'm still
searching.
Greg K
