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.
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.
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.
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;
GET
Transfers data from server to client
HEAD
Transfers HTTP headers for the equivalent GET request
PUT
Transfers data from the client to the server
POST
Transfers data from the client to the server
PATCH
Transfers data from the client to the server
DELETE
Specifies that the data on the server should be deleted
OPTIONS
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.
English 
Français