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.

Contents

• 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 
• 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 
           Extract: Sockets***NEW!
• Chapter 18 Asyncio And Servers
• Chapter 19 Direct To The Hardware
           Extract: Direct To The Hardware

Also of interest:

Raspberry Pico File System

<ASIN:B0BR8LWYMZ>

<ASIN:B0BL1HS3QD>

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; 

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.