The Pico In MicroPython: HTTP Client
Written by Harry Fairhead & Mike James   
Monday, 02 January 2023
Article Index
The Pico In MicroPython: HTTP Client
A Custom Server
A Temperature Sensor Client

Implementing a web client is a basic task for anyone wanting to make use of the internet and the simplest way to do it is to use the urequests module. This is an extract from our book all about the Raspberry Pi Pico in MicroPython.

Programming the Raspberry Pi Pico/W In MicroPython Second Edition

By Harry Fairhead & Mike James


Buy from Amazon.


  • Preface
  • Chapter 1 The Raspberry Pi Pico – Before We Begin
  • Chapter 2 Getting Started
  • Chapter 3 Getting Started With The GPIO
  • Chapter 4 Simple Output
  • Chapter 5 Some Electronics
  • Chapter 6 Simple Input
             Extract: Simple Input 
  • Chapter 7 Advanced Input – Events and Interrupts
  • Chapter 8 Pulse Width Modulation
             Extract: PWM 
  • Chapter 9 Controlling Motors And Servos
             Extract: DC Motors
  • Chapter 10 Getting Started With The SPI Bus
  • Chapter 11 A-To-D and The SPI Bus ***NEW!
  • Chapter 12 Using The I2C Bus
  • Chapter 13 Using The PIO   
  • Chapter 14 The DHT22 Sensor Implementing A Custom Protocol
             Extract: A PIO Driver For The DHT22  
  • Chapter 15 The 1‑Wire Bus And The DS1820
  • Chapter 16 The Serial Port
  • Chapter 17 Using The Pico W - WiFi
             Extract: HTTP Client 
  • Chapter 18 Asyncio And Servers
  • Chapter 19 Direct To The Hardware
             Extract: Direct To The Hardware

Also of interest:

Raspberry Pico File System





The Pico and the Pico W are very similar and all of the programs presented so far work on both models. The important difference between them is that the Pico W has additional hardware that enables it to use WiFi. From the programming point of view, however, the task is to learn how to use the new WiFi driver and the LwIP library that provides higher-level networking. This is made more difficult than need be by the inadequate documentation provided for both. This will probably improve over time.

In chapter but not in this extract

  • The Pico W
  • The WLAN Class
  • A Practical Connect
  • WiFi Scan

A Simple HTTP Client

The simplest way to make use of a WiFi connection is to work with an HTTP server. This is simple because the difficult parts of the transaction are handled by the server making the client much easier to implement. MicroPython makes this even easier by providing urequests which is a port of the Python requests module. This has methods that implement the standard HTTP transactions and a request object which wraps the data involved in the transaction.

The urequests module should work on any MicroPython implementation and it is built on top of the sockets module which is discussed later. The sockets module provides a lower-level interface to the network and urequests uses this to implement the HTTP protocol. While HTTP was invented to allow the transport of HTML pages, it can be used to transfer any data between the client and the server.

It is important to understand what the distinction is between the client and the server. In this case the client initiates the connection and the server accepts the connection. The connection once established it two-way – the client can send data to the server and vice versa. This said, HTTP is most commonly used to send data from the server to the client in the form of web pages.

Request Methods

HTTP supports a number of request methods which transfer data. Usually these are described in terms of what they do to resources hosted by a web server, but from our point of view what matters is what happens to the data.

The HTTP request methods available are; 


Transfers data from server to client


Transfers HTTP headers for the equivalent GET request


Transfers data from the client to the server


Transfers data from the client to the server


Transfers data from the client to the server


Specifies that the data on the server should be deleted


Transfers data from the client to the server

If you know about HTTP request methods you will find the above list disconcerting. If you don’t know about HTTP requests then you will be wondering why there are so many requests that transfer data from the client to the server? The answer is that in the HTTP model the server stores the master copy of the resource – usually a file or a database entry. The client can request a copy of the resource using GET and then ask the server to modify the resource using the other requests. For example, the PUT request sends a new copy of the resource for the server to use, i.e. it replaces the old copy. POST does the same thing, but PUT should be idempotent which means if you repeat it the result is as if you had done it just once. With POST you are allowed side effects. For example, PUT 1 might just store 1 but POST 1 might increment a count.

Another example is where you sends some text to the server to save under a supplied file name. For this you should use a PUT as repeating the request with the same text changes nothing. If, on the other hand, you supply text to the server and allow it to assign a name and store it then you should use a POST as you get a new file each time you send the data, even it is the same.

Similarly the PATCH request should be used by the client to request that that server makes a change to part of an existing resource. Exactly how the change is specified depends on the server. Usually a key value scheme is used, but this isn’t part of the specification.

Notice that all of these interpretations of the HTTP request methods are “optional” in the sense that it is up to you and the server you are using to interpret them and implement them. If you write your own server, or server application, then you can treat POST as if it was PUT and vice versa.


Last Updated ( Monday, 02 January 2023 )