I have a simple Restful service being called from a console app so am using WebClient. I am wondering if this call for Delete is correct.
The url looks like localhost/RestService1/Person/1
using (var client = new WebClient())
{
client.UploadString(url, "DELETE", "");
}
I don't like that UploadString does not have an overload without a data parameter. The passing of an empty parameter is not sitting well with me. Is there a better method to use for a DELETE?
I could use WebRequest but I want to just use WebClient to keep it consistent.
Here is the WebRequest block
var request = WebRequest.Create(url);
request.Method = "DELETE";
var response = (HttpWebResponse)request.GetResponse();
Both blocks work fine but what is best? Or is there a better way?
The following works for me:
client.UploadValues(url, "DELETE", new NameValueCollection());
The WebClient class doesn't really lend well to restful api consumption, I've used 3rd party libraries like RestSharp in the past that are geared more towards this type of web request. I'm pretty sure RestSharp just uses HttpWebRequest under the covers, but it provides a lot of semantics that make consuming and reusing rest resources easier.
Go get the Microsoft.Net.Http client libraries http://nuget.org/packages/Microsoft.Net.Http
HttpClient is a much better client to use for working with an API.
Sorry this is my solution in vb.net i sure that anyone can translate to c#
It's very important to drop headers, i had to comment header about Accept and Content-Type and work fine..... of course I did send the token
Dim rest As WebClient = New WebClient()
rest.Headers.Add(HttpRequestHeader.Authorization, "Bearer " & Token)
'rest.Headers.Add(HttpRequestHeader.Accept, "application/json")
'rest.Headers.Add(HttpRequestHeader.ContentType, "application/json")
result = System.Text.Encoding.UTF8.GetString(rest.UploadValues(host_api & uri, "DELETE", New NameValueCollection()))
Related
I received a Postman json collection from an API vendor that works perfectly, but has something mystifying to me: The request is in a GET format, yet there is an x-www-form-urlencoded body.
URL: https://login.microsoftonline.com/d1e<secret>9563/oauth2/token
And when I look at the postman-generated c# code, the mystery continues:
var client = new RestClient("https://login.microsoftonline.com/d1e...d3/oauth2/token");
client.Timeout = -1;
var request = new RestRequest(Method.GET);
request.AddHeader("Content-Type", "application/x-www-form-urlencoded");
request.AddParameter("grant_type", "client_credentials");
request.AddParameter("client_id", "c06bb...79");
request.AddParameter("client_secret", "7~u...D");
request.AddParameter("resource", "https://vault.azure.net");
IRestResponse response = client.Execute(request);
Console.WriteLine(response.Content);
Note the AddParameter constructions for a GET call. To me, this must be a slight-of-hand for merely adding those values to the querystring. But when I look at the postman console I see:
In the postman console I would have expected to see those params appended to the url as a querystring, and then everything would have made sense. But you can see that it's a bonafide Request Body.
When I make GET calls in my c# code I like to use the simple yet solid WebClient object to call the DownloadString() method. But this method is only for GETs and there's no way to send a form-post style body, understandably.
Is postman truly sending a GET with all those values being appended to the url as a querystring? And should I do the same in my DownloadString() call? Or is there something else going on here? Should I instead, in my c#, be calling the UploadString() method and sending a form post BODY as a GET??
Http protocol supports adding a body to a request, but the WebClient class you use doesn't. Presumably because it isn't considered the norm.
I'm sure there's good reasons for Microsoft using it in the OAuth flow though. Those guys normally do things right!
HTTP GET with request body
API is just an abstraction , you can send what ever you want to the API . It depends on the implementation , how the server handles these data.
Some services considers only what it requires and ignores other information
some services considers the entire requests and validates that it has only the allowed data. what should be allowed depends on the service
Postman is just a client that sends data to server , its upto you to decide what all information it should send . If you dont need any body then keep it as none. if you need some thing then add it.
I am facing a issue with mailChimp, I make a PUT call with HttpWebRequest for unsubscribing a user from the list, it works fine but the same thing I had done with POST call with status as unsubscribed then it also works. So which call should I make for unsubscription?
Example code with mailChimp Api key in added in HttpWebRequest headers:
string subscriberEmail = "XXXXXX";
//Create JSON Object for sending to MailChimp
var subscribeRequest = new
{
status = "unsubscribed",
email_address = subscriberEmail, //E-Mail
};
var requestJson = serializer.Serialize(subscribeRequest);
HttpWebRequest httpWebRequest =(HttpWebRequest)HttpWebRequest.Create(https://XXX.api.mailchimp.com/3.0/lists/XXXXXX/members");
httpWebRequest.Method = "POST";
httpWebRequest.ContentType = "text/json";
httpWebRequest.Accept = "text/json";
Rather than a hard-rule on what to choose, here is an explanation on why both Verbs work.
A lot of API providers support the same operations for both the PUT and POST verb.
In pure REST terms, these verbs have specific guidelines of POST for creating new resources and PUT for updating resources.
But in most real-world APIs, the lines blur between following 100% REST guidelines vs. providing action oriented APIs. e.g. (Unsubscribe, Cancel etc.)
In that, it really doesn't matter if you use POST or PUT and hence a lot of API providers provide support for both. Internally they tend to always go through the same code path, and hence you should see the same behavior in both cases.
When both PUT and POST are available for action oriented APIs (unsubscribe, cancel etc.) I have seen folks preferring the POST Verb, since it is more intuitive and natural on a non-read-only API.
But there is really no hard rule, so whatever you decide stick to it.
i'm having a little piece of python code which makes a web request using the urllib2 as you can se below
import json
import urllib2
urlRequest = urllib2.Request('<link>')
urlRequest.add_header('Content-Type', 'application/json')
urlRequest.add_header('RegistrationToken', '<token>')
data = {
'content': '<c>',
'messagetype': 'RichText',
'contenttype': 'text',
'id': '<id>'
}
urllib2.urlopen(urlRequest, json.dumps(data))
As i was trying to do it in C# i came across the following problems
how to i send the data
how do i add the headers?
After googling for a while i managed to write this code:
var request = (HttpWebRequest)WebRequest.Create(url_input.Text);
request.ContentType = "application/json";
request.Headers["RegistrationToken"] = rtoken_input.Text;
request.GetResponse();
I managed to deal with the headers part but the question on the data still remains. Also what is the best way to json encode something?
Anyone who knows what to do?
If you are after serializing the POST data to a JSON payload there are few options.
1) System.Web.Helpers.Json.Encode MSDN Link
2) using the JSON.NET library Link
As for your attempt on converting python to C# you are on the correct track.
Refer to this link
Alternatively you could make use of the WebClient class MSDN Link
Refer to this link as well
Pseudo code
var client = new WebClient();
client.Headers.Add("Content-Type", "application/json");
client.Headers.Add("RegistrationToken", "<token>");
string response = client.UploadString("<link>", "<json string>");
What is the equivalent to WebResponse.IsFromCache when using HttpClient and HttpResponseMessage?
Is there some HTTP header in the response that I can look at?
FYI: The Windows.Web.Http HttpClient (a similar API targetted at Windows 8.1 app development) does include an HttpResponseMessage.Source field that specifies where the result came from (common values are "cache" and "network").
The Windows.Web.Http classes are usable from C# and other .NET languages, from C++, and from JavaScript (when running as a WwaHost app like from the Windows app store).
Can I ask what you're trying to achieve? Are trying to avoid caching?
The reason for asking is I've looked at the source code for HttpClient (specifically HttpClientHandler) and the source for HttpWebResponse and I dont believe you can get this information from the headers.
HttpClient/HttpClientHandler does use HttpWebResponse internally however it does not expose all properties from HttpWebResponse :
private HttpResponseMessage CreateResponseMessage(HttpWebResponse webResponse, HttpRequestMessage request)
{
HttpResponseMessage httpResponseMessage = new HttpResponseMessage(webResponse.StatusCode);
httpResponseMessage.ReasonPhrase = webResponse.StatusDescription;
httpResponseMessage.Version = webResponse.ProtocolVersion;
httpResponseMessage.RequestMessage = request;
httpResponseMessage.Content = (HttpContent) new StreamContent((Stream) new HttpClientHandler.WebExceptionWrapperStream(webResponse.GetResponseStream()));
//this line doesnt exist, would be nice
httpResponseMessage.IsFromCache = webResponse.IsFromCache;// <-- MISSING!
...
}
So your options the way I see it are:
a) Look at the source code for HttpWebRequest to determine the logic for IsFromCache and retrofit this somehow into HttpClient (this may not even be possible, depends on what the logic actually does/needs)
b)ask the ASP.NET team for this property to be included with HttpResponseMessage. either directly as a property or perhaps they could 'keep' the HttpWebResponse
Neither of these options are that great sorry, hence my original question, what are you trying to acheive?
I've been struggling with this scenario recently as well.
What I needed was an integration test to verify that:
Responses for a newly created resource had the correct headers set by the server.
Subsequent requests for that resource were fulfilled from the client-cache.
Responses for an existing resource had the correct headers set by the server as well.
What I ended up doing was a twofold check:
A non-caching HttpClient to check the initial response:
new WebRequestHandler
{
AllowAutoRedirect = true,
UseCookies = true,
CookieContainer = new CookieContainer(),
CachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.Refresh)
};
var client = new HttpClient(handler)
and a second HTTP client to check the client-side cache:
new WebRequestHandler
{
AllowAutoRedirect = true,
UseCookies = true,
CookieContainer = new CookieContainer(),
CachePolicy = new HttpRequestCachePolicy(HttpRequestCacheLevel.Default)
};
var client = new HttpClient(handler)
To verify the source of response messages I compare the HttpResponseMessage.Headers.Date values from steps 1 and 2 (which will be the same if the response came from the client cache). For my third step I can just re-use the client from the first step and append an arbitrary string to the URL.
Disclaimer: this applies to .NET Framework 4.7 and ignores best practices concerning HttpClient usage but is seems to do the trick for me in my test suite. An explicit property like the one mentioned above would be preferable but does not seem to be available. Since the last reply here is already a few years old there might be better ways to handle this, but I couldn't think of one.
I am new to C#, I need to send HTTP GET request and read answer. I am familiar with Java and easy can do it URLConnection class but I don't know in c#. Can anybody help ?
The simplest way is to use WebClient:
WebClient client = new WebClient();
string text = client.DownloadString(url);
(That's the synchronous form; it also supports asynchronous requests.)
For more control you might want to use HttpWebRequest.