Godot-proposals: Make `HTTPRequest.request()` return the response instead of emitting a signal

Created on 6 Nov 2020  路  5Comments  路  Source: godotengine/godot-proposals

Describe the project you are working on: A web crawler/interface for an internet forum.

Describe the problem or limitation you are having in your project: Because HTTPRequest.request() emits a signal containing the response to the request instead of the response itself, it's very cumbersome to make sequential requests. Instead of simply doing var response = http.request(url) and using it as necessary, you have to:

  1. connect the HTTPRequest node to a receiver function that may vary based on the type of request
  2. in the receiver function, either pass the response back to the function the request was initiated from, or make it a global
  3. if you now want to use that HTTPRequest node for a different request that has to be interpreted a different way (i.e. it would have a different receiver function), you now have to disconnect it from the previous receiver function and connect it to the new one.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: It makes the process of multiple sequential requests entirely less cumbersome and confusing to manage, and brings it in line with how HTTP libraries in other languages (python requests for example) usually operate.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

var response = http.request(url)
print(response.body)

Depending on how HTTPRequest.request() was implemented behind the scenes, it could be non-blocking and thus require a yield or 4.0 await to apply sequentially, e.g.:

var response1 = yield(http.request(url), "completed")
print(response1.body)
var response2 = yield(http.request(url), "completed")
print(response2.body)

If this enhancement will not be used often, can it be worked around with a few lines of script?: Anyone who uses the HTTPRequest node would be using this constantly, and if there's a simple workaround, I'm not aware of it.

Is there a reason why this should be core and not an add-on in the asset library?: It is a fundamental change to a built-in node.

network

Most helpful comment

TIL HTTPRequest is a node... I think we should make it a singleton instead with this new behaviour- Perhaps for 4.0 we should rework HTTPRequest?

All 5 comments

TIL HTTPRequest is a node... I think we should make it a singleton instead with this new behaviour- Perhaps for 4.0 we should rework HTTPRequest?

You can't make HttpRequest.request() return a response without making it blocking, which is not a good tradeoff imo.

You can't make HttpRequest.request() return a response without making it blocking, which is not a good tradeoff imo.

It can return a GDScriptFunctionState which can be await-ed in Godot 4.0

var response = await HTTPRequest.request("https://example.com/")

You can't make HttpRequest.request() return a response without making it blocking, which is not a good tradeoff imo.

It can return a GDScriptFunctionState which can be await-ed in Godot 4.0

var response = await HTTPRequest.request("https://example.com/")

Right, but that's not returning the response itself. That's returning a "future" (or "promise" or w/e you want to call it) that can be used to get the response--which i think we absolutely should do for 4.0. But that's not the same thing.

Understood, let's make those changes for 4.0 only since they're compatibility breaking regardless.

Was this page helpful?
0 / 5 - 0 ratings