I have a very basic Web API example that I constructed using the example code from this tutorial:
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
public class Survey
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}
public class SurveysController : ApiController
{
public IEnumerable<Survey> All()
{
using (ITSurveyEntities model = new ITSurveyEntities())
{
return new List<Survey>(
from s in model.Surveys
select new Survey
{
Id = s.Id,
Name = s.Name,
Description = s.Description,
});
}
}
}
and it's leveraging ITSurveyEntities
, which was a generated ADO.NET Entity Data Model from the database, which only contains a single table right now, Survey
.
In short, I don't think I'm trying to do anything special here.
When I try and navigate to the API using something like http://localhost:1681/api/surveys
, I get a response, but the file is named surveys
with no extension. Further, if I try and Save As
and give it say a txt
extension, the download just fails.
I would expect that the API would return a file names surveys.json
, like the example project does with products
, and the browser would ask me to open or save the file.
I have compared the Web.config
files between my project and the example code from the tutorial that works.
I have compared the routing configuration between my project and the example code from the tutorial that works.
I've tried to exclude WebDav because my searches have indicated that it might be the cause. I did that by modifying the Web.config in a manner that matches what's on this blog.
Okay, after the guidance by Joe Enos I found that the issue was that the view model was named Survey
also and so it was throwing an error about ambiguity between the CLR type and the EDM type.
I resolved that by renaming the view model to SurveyViewModel
, and the request to http://localhost:1681/api/surveys
now returns a HTTP 200
and downloads the file as expected.
Another way to improve the performance of your API calls is by sending and receiving only the portion of the data that you're interested in. This lets your application avoid transferring, parsing, and storing unneeded fields, so it can use resources including network, CPU, and memory more efficiently.
API testing flow is quite simple with three main steps: Send the request with necessary input data. Get the response having output data. Verify that the response returned as expected in the requirement.
To fix this, check with your API provider to see if there is a testing environment that doesn't utilize caching. Alternatively, double check your API call on a different machine or with a different set of credentials. You can also check your API documentation to see if there's some cache invalidation method available.
API failures happen for multiple reasons, but most of them can be boiled down to these three culprits: Software changes happening too quickly. Breakdowns in communication among teams. Bad data that is incompatible with your API.
If you take a look at the raw request and response using Fiddler or your browser's dev tools, you should find some clues as to the problem.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With