Open CalinBunea opened 8 years ago
Hi @CalinBunea the generation is using the API Explorer from within ASP.NET to determine the correct verb and is not per convention directly, however the route resolver in ASP.NET uses convention if the verb is not explicitly defined on the action.
Can you provide me with a snippet of your controller?
Well when I access my webservice /api/proxies for that specific method I have
getPsPopularityDataForSearchPhrases: function(countryPrefix,searchPhrases,options) {
var defaults = { fields: [] };
var settings = $.extend({}, defaults, options || {});
var url = "api/Munin/GetPsPopularityDataForSearchPhrases?countryPrefix=" + countryPrefix;
if(settings.fields.length > 0) {
url += url.indexOf("?") == -1 ? "?" : "&";
url += "fields=" + settings.fields.join();
}
return invoke.call(this, url, "post",
{
countryPrefix: countryPrefix,
}
, searchPhrases);
},
the method in controller:
[HttpPost]
public List
and the generated client proxy
public virtual List
EnsureSuccess(result);
return result.Content.ReadAsAsync<List<PsPopularityData>>().Result;
}
Small update, I have renamed the method (to not include "get" in name) but still the verb generated is GET...
Another update: I think this issue was caused by a method overload. One of the methods didn't had [HttpPost] and probably this is why the second method (overloaded) which has [HttpPost] was still generated to use verb GET.
It looks like sometimes the generated Http verb ("GET","POST","DELETE","PUT") is generated based on method name... So if my webservice method name is "DeleteMyStuff" the proxy generated on client will try to use verb "DELETE" although my webservice does not support "DELETE" verb. Same for method named like "GetMyStuff" having [HttpPost] attribute - on client it generates sometimes verb GET instead of verb POST which will result in an error because server does not support GET verb for that method.