Requests
| Created at | 20 Feb 2024 |
| Editor(s) | Alejandro Carmena Magro , JD-017 Machine Learning Ops |
| Supervisor(s) | Alfonso Medela , JD-005 Technical Manager & Person Responsible for Regulatory Compliance |
| Approval | - Approved |
Description​
Requests is a powerful HTTP client for sending HTTP/1.1 requests extremely easily. Unlike the built-in urllib library, Requests is more user-friendly and does not require manual handling of query strings or form-encoded data.
General details​
- Developer(s): Primarily developed by Kenneth Reitz. However, it has received contributions from many developers over the years.
- Open source: Yes
- Language(s): Python
- Repository: https://github.com/psf/requests
- License: Apache License 2.0
- Operating system(s): OS Independent (can run on any operating system that supports Python)
- Actively maintained: Yes (last code commit was one week ago)
Intended use on the device​
The SOUP is used in the medical device for the following specific purposes only:
- Define and send HTTP requests that allow internal intercommunication between the device's microservices.
- Request data from other trusted services external to the device.
Requirements​
For the integration and safe usage of this SOUP within a software system, it's important to outline both functional and performance requirements. These requirements help mitigate risks and ensure compatibility and performance standards are met.
Functional​
- HTTP request methods: Support various HTTP request methods such as GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH to interact with web services.
- Diverse content: Support sending and receiving various types of content, such as JSON, form data, and binary data, with appropriate encoding and decoding mechanisms.
- Session management: Provide a way to persist certain parameters across requests. Session objects can help manage cookies, headers, and other recurring attributes of requests.
- SSL verification: Support for SSL/TLS verification for secure HTTP requests. It should be able to work with custom certificates as well as provide an option to bypass verification in controlled environments for testing purposes.
- Custom headers: Send custom headers with requests is necessary for interacting with many servers that require authentication tokens or other specific information.
- Timeouts: Support setting timeouts to ensure that requests do not hang indefinitely, allowing the system to handle delays in network communication gracefully.
- Error handling: Robust error handling mechanisms should be in place to manage and recover from network-related errors gracefully. This includes handling HTTP error codes, timeouts, and connection errors.
Performance​
- Efficiency: Handle network communication efficiently, with minimal overhead. It should be optimized for speed and minimise memory usage where possible.
- Concurrency: Compatible with asynchronous programming models or external tools that allow for concurrent HTTP requests. This is crucial for high-load applications that need to make many requests simultaneously.
- Scalability: Perform consistently under different loads. Its performance should scale linearly with the number of requests made, without unexpected degradation as the load increases.
- Resource management: Manage system resources wisely, ensuring that connections are released back to the system promptly and that there are no memory leaks.
System requirements​
Establishing minimum software and hardware requirements is important to mitigate risks, such as security vulnerabilities, performance issues, or compatibility problems, and to ensure that the SOUP functions effectively within the intended environment.
Software​
After evaluation, we find that there are no specific software requirements for this SOUP. It works properly on standard computing devices, which includes our environment.
Hardware​
After evaluation, we find that there are no specific hardware requirements for this SOUP. It works properly on standard computing devices, which includes our environment.
Documentation​
The official SOUP documentation can be found at https://requests.readthedocs.io/en/latest/
Additionally, a criterion for validating the SOUP is that all the items of the following checklist are satisfied:
- The vendor maintains clear and comprehensive documentation of the SOUP describing its functional capabilities, user guidelines, and tutorials, which facilitates learning and rapid adoption.
- The documentation for the SOUP is regularly updated and clearly outlines every feature utilized by the medical device, doing so for all integrated versions of the SOUP.
Related software items​
We catalog the interconnections between the microservices within our software architecture and the specific versions of the SOUP they utilise. This mapping ensures clarity and traceability, facilitating both the understanding of the system's dependencies and the management of SOUP components.
Although the title of the section mentions software items, the relationship with SOUP versions has been established with microservices (also considered software items, by the way) because each one is inside a different Docker container and, therefore, has its own isolated runtime environment.
| SOUP version | Software item(s) |
|---|---|
| 2.31.0 | WEB API GATEWAY REPORT BUILDER APASI-API ASCORAD-API |
Related risks​
The following are risks applicable to this SOUP from the table found in document R-TF-013-002 Risk management record_2023_001:
- 58. SOUP presents an anomaly that makes it incompatible with other SOUPs or with software elements of the device.
- 59. SOUP is not being maintained nor regularly patched.
- 60. SOUP presents cybersecurity vulnerabilities.
Lists of published anomalies​
The incidents, anomalies, known issues or changes between versions for this SOUP can be found at:
History of evaluation of SOUP anomalies​
28 Feb 2024​
- Reviewer of the anomalies: Alejandro Carmena Magro
- Version(s) of the SOUP reviewed: 2.31.0
No anomalies have been found.
Record signature meaning​
- Author: JD-004
- Reviewer: JD-003
- Approver: JD-005