…API/emailMessage/?emailId=test123
I have written the above URL using Web API to get the email in JSON data format(email body, sender, CC, To, etc).
Also, I have the requirement to allow download of email along with attachment for the same URL.
One way to do it is using content negotiation. I can use “MediaTypeHeaderValue("application/octet-stream")” to send the content as downloadable.
Question is….
1. Which parameter in the GET request the user should request for JSON content or download of content? Or what is the correct way of asking the content type from HTTP client?
2. On the server side I can read what content type the user is asking and send the appropriate data just using case statement. Is there anything to be considered on the server side in this scenarios?
Thank you,
Eric
The Accept request header is used to inform the server what media types the client supports. However, do not be concerned about adding a format= parameter to your URI to request a different format. It will not have a negative impact on your application.
Related
I am working with this third party service provider where i have to fetch / filter some data from them. The search filter parameters are complex in nature and contains too many filter params. I have tried to use querystring values and with querystring, i find it more difficult to send data since the data i have to send may contain an array of objects.
With JSON request body even with HTTP GET request, I find it extremely easy to process the request and did the testing using Insomnia REST client with ease. However POSTman REST client doesn't allow to send body parameters with GET request.
I have seen others using POST request to fetch / filter data from the api for the same purpose. POST HTTP request can be used to fetch data, but is it good from the technical standpoint? Is it recommended practice to send JSON request body values with GET request?
Not sure how much control you might have on the protocol or you have any middleware, but an HTTP GET usually doesn't have a body, I've even seen smart firewalls and hosting services strip any body by default. If you want to stay "close" to clean REST, you might consider adding a "/query" to your resource path and do a POST to that endpoint; it's a bit "RPC-ish" but not too bad. Another option would be to have a completely independent query service that could be using another protocol such as JSON-RPC.
I'm creating a headless API that's going to drive an Angular front end. I'm having a bit of trouble figuring out how I should handle user authentication though.
Obviously the API should run over SSL, but the question that's coming up is how should I send the request that contains the user's password: over GET or POST. It's a RESTFUL API, so what I'm doing is retrieving information meaning it should get a GET request. But sending the password over get means it's part of the URI, right? I know even a GET request is encrypted over HTTPS, but is that still the correct way? Or is this a case to break from RESTFUL and have the data in the body or something (can a GET request have data in the body?).
If you pass the credentials in a request header, you will be fine with either a GET or POST request. You have the option of using the established Authorization header with your choice of authentication scheme, or you can create custom headers that are specific to your API.
When using header fields as a means of communicating credentials, you do not need to fear the credentials being written to the access log as headers are not included in that log. Using header fields also conforms to REST standards, and should actually be utilized to communicate any meta-data relevant to the resource request/response. Such meta-data can include, but is not limited to, information like: collection size, pagination details, or locations of related resources.
In summary, always use header fields as a means of authentication/authorization.
mostly GET request will bind data in URL itself... so it is more redable than POST..
so if it is GET, there is a possibility to alive HISTORY LOG
Using ?user=myUsername&pass=MyPasswort is exactly like using a GET based form and, while the Referer issue can be contained, the problems regarding logs and history remain.
Sending any kind of sensitive data over GET is dangerous, even if it is HTTPS. These data might end up in log files at the server and will be included in the Referer header in links to or includes from other sides. They will also be saved in the history of the browser so an attacker might try to guess and verify the original contents of the link with an attack against the history.
You could send a data body with a get request too but this isn't supported by all libraries I guess.
Better to use POST or request headers. Look at other APIs and how they are handling it.
But you could still use GET with basic authentication like here: http://restcookbook.com/Basics/loggingin/
I'm designing a REST api that allow client side to POST (create) a resource.
Let's call my resource is Subscription and my REST api accepts a Dto called Subscription
The POST request needs to be sent together with a captcha token that will be verified on server side.
My question is where would be the best place to put the captcha token, there're some options that I'm thinking about:
Directly inside Subscription
As a parameter in URL, e.g: /subscriptions?captcha_token=abcd1234
As a HTTP header
Create a new Dto that wraps Subscription and carry field captchaToken
Any other suggestion are welcome.
Thank you.
For anything authentication or authorization related I typically rely on headers or querystring parameters.
Generally I don't like to commingle payload with auth-related material, nor do I like to encapsulate it.
Having it in an HTTP header or as a querystring parameter gives you a good amount of isolation there. Also since it's independent of the request body you can implement broader auth controls for every API call without being dependent on the presence of a request body (important for GET requests which shouldn't carry a request body anyway).
Using a HTTP Header is only an option if your clients can modify / send HTTP Header information. This approach does not work for Standard Browsers.
You are not filtering a resource, so a query parameter from the REST Point of view does not make sense, and you don't want to send the captcha answer as query parameter.
Usually the one submits the captcha information (id, answer) together with the form data (payload). You also usually display captchas together with the form.
So at the end the only useful option is to send the captcha information as part of the payload / form data.
If you should put the data into your Subscription DTO or not depends on your design / preferences.
I'd suggest to use something like a Subscription(Data) and SubscriptionRequest where the SubscriptionRequest contains the SubscriptionDataand the Captha Information (capcha id and answer)
I'm trying to programmatically submit a form on a web site that I do not own. I'm trying to simulate what I would manually do with a web browser. I am issuing an HTTP POST request using an HTTP library.
For a reason that I don't know I am getting a different result (an error, a different response, ...) when I programmatically submit the form compared to a manual submission in a web browser.
How can that be and how can I find out what mistake I have made?
This question is intentionally language and library agnostic. I'm asking for the general procedure for debugging such issues.
All instances of this problem are equivalent. Here is how to resolve all of them:
The web site you are posting to cannot tell different clients apart. It cannot find out whether you are using a web browser or an HTTP library. Therefore, only what you send matters for the decision of the server on how to react.
If you observe different responses from the server this means that you are sending different requests.
A few important things that you probably have to send correctly:
URL
Verb (GET or POST)
Headers: Host, User-Agent, Content-Length
Cookies (the Cookie and Set-Cookie headers)
The request body
Use an HTTP sniffer like Fiddler to capture what you are programmatically sending and what your browser is sending. Compare the requests for differences. Eliminate the differences one by one to see which one caused the problem. You can drag an HTTP request into the Composer Window to be able to modify and reissue it.
It is impossible to still get a different result if you truly have eliminated all differences between the manual and the programmatic requests.
I am going to develope REST(without any framework like SPRING) services which can accept xml. I am going to create XSD for the input xml format.
Now, when client sends some invalid xml which is not as per schema, how should i validate it? Do i need to write a specific code to validate. Can't it get failed in the client side itself?
Previously we had soap service, so if i try to send soap request which is not as per schema, soapui will throw error. The request even will not come to server i guess.
I hope you understood my question, please clarify.
RESTful clients are free to transmit any content they wish to the server, and even try to negotiate different encoding formats like JSON instead of XML. That's part of the power of REST.
It's up to the server to validate that clients send correctly encoded data in the payload, and return a 400-range status code such as 400 - Bad Request if they do not.
You will need to write all your server validation code yourself unless the REST API framework on the server side provides it for you.