-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Different appoach for HTTP Client directly using the Stream, alternative to HTTPClient #3848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…8266HTTPClient / HTTPClient
…, because ArduinoJson is not part of the standard libraries
Checks failed for PlaformIO on ubuntu-latest with |
@Jeroen88 , have the same issue with my pull request. And I have simply added upload speed options for 4 boards. |
How did you do that? |
Do you mean the upload speed options? If so - I just added in the file boards.txt submenu for the respective boards with the options (basically I copied it from the other boards). you can check it out: |
…g for the server response. Not tested yet
…mber of bytes written to the printer
Thnx for the advise, but this did not solve the check problem. Your PR #3849 has the same problem |
Yes, that's what I said, but now I realized that it sounded like it solved the problem (which is not the case). :) I still look for a solution :) |
If you have a solution please share! :) UPDATE: solution in next commit (in file install-platformio-esp32.sh) |
… if, on a reused connection, ::status() returns a negative value indicating a failure. The example ReuseConnectionClientHTTPS.ino is adapted accordingly
…ws two pairs of quotes otherwise
…eep it alive during the full running of the sketch
Does this conform to the Arduino API such that it would be a replacement for HTTPClient if the names were changed? If not, it should be separated into its own repo and submitted to arduino for inclusion as a 3rd party library. |
@lbernstone thnx for your suggestion. I never realized that the Arduino API should be followed to have a library added to this repo. No, it has a different API. I might follow your suggestion and submit it to Arduino. Closing for now. |
I don't speak for espressif or @me-no-dev, but my feeling is that since Arduino has a good method for 3rd party extensions, this codebase should adhere pretty strictly to providing the core Arduino API. The existing HTTPClient has some major issues, so it would be nice to get a compatible replacement 😄 |
@lbernstone I think it should be relatively simple to make a wrapper around it that delivers the Arduino API, but it is quite some time ago that I created this library (although I am using is every day without any issues for WiFiClientSecure and a mobile NB-IoT client). Could you give the examples a try and tell me what you think? Especially if it is worth the effort to write a wrapper in your opinion? |
I think it is far more important to write a good library than to force it into an API written 10 years ago. I'm not the best person to test this, but will direct people having issues to your code. |
ClientHTTP
The
class ClientHTTP
implements support for REST API client calls to a HTTP server. It inherits fromClient
and thus implements a superset of that class' interface.The
class ClientHTTP
decorates the underlying stream with HTTP request headers and reads the HTTP response headers from the stream before the stream is made available to the program. Also chunked responses are handled 'under the hood' offering a clean stream to which a request payload (if any) can be written using the standardPrint
functions likePrint::write()
,Print::print()
andPrint::printf()
, and from which response payloads (if any) can be read using the standardStream::read()
functions.The
class ClientHTTP
has a smaller memory footprint than the alternativeclass HTTPClient
. Moreover: because of theStream
oriented nature ofclass ClientHTTP
no memory buffers are needed, neither for sending payload, nor for receiving payload. It still remains possible to use such memory buffers though.Chunked response from the stream is correctly implemented.
No Strings are used to prevent heap fragmentation. Only small stack buffers are used. Two exceptions are: the host name is copied into a heap
char array
, and therequestHeaders
andresponseHeaders
are dynamic standard containers (map) usingstd::string
for both key and value.class ClientHTTP
is capable of handling redirections. If not needed support for this may be omitted by removing the#define SUPPORT_REDIRECTS
in the header file, thus saving some program memory bytes.Request headers can easily be set by
class ClientHTTP
. Response headers can be easily collected byclass ClientHTTP
.Any client may be used, e.g.
WiFiClient
,WiFiClientSecure
andEthernetClient
.A HTTP
GET
,HEAD
,POST
,PUT
,PATCH
orDELETE
always follows the same skeleton.Integration with ArduinoJson, version 5 and 6, both for sending and receiving Json payloads is very intuitive.
The same library is defined for both the ESP8266 and the ESP32.
The following examples are available. All but one are HTTPS / TLS 1.2 examples:
GET
a payload from a HTTP server and print it toSerial
GET
a payload from a HTTPS server and print it toSerial
GET
a payload from a HTTPS server and handle the data usingStreamString
or auint8_t buffer[]
POST
a payload to a HTTPS server and print the response toSerial
POST
an ArduinoJson to a HTTPS server and deserialize the response into another ArduinJson without buffers. All data is buffered into the ArduinoJson onlyclass Sizer
first. Next the resulting length is used to set theContent-Length
request header by callingPOST
Connection: close
response header. This example DOES NOT WORK on the ESP8266 YET!Still to be done:
Request and response headers
Request headers can be set by just defining them before calling the REST method (
GET
,POST
, etc):Response headers can be collected by just defining them before
::status()
is called:http.responseHeaders["Content-Type"];
After the
::status()
commandresponseHeaders['Content-Type']
is either an empty string if the server did not send the response header, or it is populated with the value sent.Skeleton program
A HTTP REST API call always follows the following skeleton
WiFiClient client
orWiFiClientSecure client
ClientHTTP http(client)
, passing the transport client into the constructorhtpp.connect(host, port)
http.POST(payload, payloadLength)
Print::write()
,Print::print()
andPrint:printf()
http.status()
which reads the response headers from the stream and returns the HTTP response code (greater than 0) or an error code (less than 0)Stream::read()
commandshttp.stop()
, or reuse the connection if the server did not sent aConnection: close
response header, nor closed it's side of the connectionArduinoJson integration
ArduinoJson documents, both version 5 and version 6, can directly be POSTed to a REST server:
Also ArduinoJson documents, both version 5 and 6, can directly be deserialized from the response:
See the examples for how to use ArduinoJson 5 .