How can I pass in http.get(url, options) data in the body.
I know I can pass data to Header but I would like to pass data in the body in the JSON format.
Is it possible to do this with this componet?
Something like this:
httpOptions = {
headers: new HttpHeaders({
‘Content-Type’: ‘application/json’
}),
body: {
“receiveCountry”: “ABW”,
“sendAmount”: 100
},
observe: ‘body’,
params: new HttpParams({}),
responseType: ‘json’,
withCredentials: false
}
and execute this.http.get(url, this.httpOptions)
Please let me know.
Don’t. As RFC 7231 says:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
In practical terms, this means that it would be perfectly reasonable for a webserver hosting your backend to dump this request on the floor at a very low level. This is why HttpClient’s get does not take a payload parameter.
Additionally, given the example you gave here of what looks like a funds transfer, this is almost the canonical poster child of something that may never ever be done by a GET request. GET requests must be idempotent and cacheable - actually having them hit the backend server once, 85 times, or even never must be acceptable, as long as the client gets back accurate data. GET can only read; never write.
Do not set Content-Type manually. Do not build custom HttpHeaders if that’s the only one you want to set. Do change this to be a POST request instead.
1 Like
Hi Silvio, could it be that what you wanted to do is to send a POST and not a GET?
POST naturally allows data in the body.
Gustavo.
Hi Silvio,
I send data using get like this:
import { HttpClient, HttpResponse, HttpHeaders, HttpParams } from ‘@angular/common/http’;
…
public get(path, params?) {
if (params == undefined) params = {};
return Observable.create(observer => {
this.getUserInfo().then((userObj) => {
let headers = new HttpHeaders().set(“Content-Type”, “application/json”)
.set(“AuthHeader”, userObj.token)
.set(“AuthKey”, userObj.key);
this.http.get(this.appConfig.baseAPIPath() + path, { headers: headers, params: params }).subscribe(
…
I then run a test server on my test computer such that I can resolve any problems. Works correctly for me on both Android and iOS.
Why are you doing this? HttpClient gives you a perfectly fine Observable. I can’t see any benefit to making another one.
Because get is a service that can be used by any of the pages within the app to get information from the server. HttpClient is an element of the get service.
It works!
I fail to see why this necessitates creating a new Observable.
If you’re happy with it, I guess that’s the most important thing.
To anybody else looking for design advice that happens to care about my opinion:
I would not suggest emulating @ptuson’s code at all, and especially in use cases like that described in the OP where the intent of the call is to modify server state. Yes, you theoretically could abuse query parameters to pass data like this through a GET request, but doing so would break a bunch of the most crucial rules for designing a REST API, as described above.
I have more technical and stylistic concerns about the way this code is written, but more importantly than any of those, I fundamentally disagree with the spirit of the structure. I think that services should traffic only in business layer objects; they should provide whatever aspects of CRUD functionality are appropriate for the app, but never expose how those business objects are gotten or stored.
Internally, they may all end up being HTTP GET or POST requests to a particular server. Maybe some of them interact with on-device storage in some way. Pages and components should neither know or care about any of that. This achieves three critical goals: clear separation of concerns, futureproofing, and testability. The backend can be changed or mocked out with zero impact outside of the service provider. There should be no notion of low-level implementation concepts like URLs or query parameters anywhere in the public surface of a service provider.
To make it very clear, I use the get parameter to tailor what is got to minimise what is sent to what the page actually wants. This does not modify the server or change its state. What it does do is speed up the response and minimise the transfer of data.
I use a post service to send data that is going to be put into the server and change its state.
Silvio asked how to add parameters to get, not what they wanted to do with it.
I am using GET because I am not creating data in this method, just querying information.
1 Like
See this comments about use or not data in the body for GET method, include that the RFC changes:
I’m not sure what you’re expecting me to look at. The OP states in the third comment that after three years of experience, they agree with the dude who coined the entire concept of REST in the first place when he says:
yes, you can send a body with GET, and no, it is never useful to do so.
So you’re not sending 100 whatevers to ABW, but you want to find all transactions that did send 100 whatevers to ABV? In that case, just add your search terms to the HttpParams instead of the body.