Skip to content

4.2-python-project.md

Latest commit

 

History

History
104 lines (76 loc) · 4.1 KB

4.2-python-project.md

File metadata and controls

104 lines (76 loc) · 4.1 KB
Raw

Python OOP Web Server Challenge

Overview

This is an open-ended challenge to design and implement a Python module that acts as a simple HTTP web server for managing simulated network device data. The goal is to use object-oriented programming (OOP) to build a reusable, extensible server class that can handle different HTTP methods and endpoints.

Challenge Specs

  • Create a Python module (e.g., my_webserver.py) that defines a class-based HTTP server.

  • OOP Required: All server logic must be encapsulated in a class (e.g., WebServer).

  • Manual HTTP Parsing: Use only the Python standard library (socket, threading, etc.). Do not use Flask, FastAPI, or http.server.

    Parse at minimum:

    • Request line: METHOD PATH HTTP/1.1 (the path is in the request line, not the body)
    • Headers until blank line (\r\n\r\n)
    • For POST/PUT, read body using Content-Length
    • You may assume requests fit in memory (no streaming required)

  • Handler Registration:

    • You must provide a way to register or override handlers for different HTTP methods and paths.
    • This can be done via class methods, decorators (bonus), or by passing functions to the class.
    • Bonus: Use abstract base classes for catch-all handlers.

  • Supported HTTP Methods:

    • GET: Return information about simulated network devices.
      • /interfaces → List of network interfaces (use psutil or os)
      • /neighbors → Simulated ARP neighbor table (dummy data)
      • /mac → MAC address info (see below)
      • /routes → Simulated routing table (dummy data, see schema below)
    • POST: Add a new route to the in-memory routing table (do NOT modify real system routes).
      • /routes → Accepts JSON body with route info, adds to in-memory list
    • PUT: Update an existing route (by ID or index) in the in-memory routing table.
      • /routes/<id> → Accepts JSON body, updates route
    • DELETE: Remove a route from the in-memory routing table.
      • /routes/<id> → Deletes route

  • All data modifications must be in-memory only.

  • All responses must be JSON.

    Every response should include:

    • Content-Type: application/json
    • Proper status codes: 200, 201, 400, 404, 405

  • Server must be startable by creating an instance and calling a method (e.g., server.serve()).

  • Bonus:

    • Use decorators for route/method registration
    • Use abstract base classes for handler methods
    • Support query parameters or path variables

Endpoints and Data Format

  • /routes uses this in-memory schema (example):

    { "id": 1, "dest": "10.0.0.0/24", "nextHop": "192.168.1.1", "iface": "Wi-Fi" }

    For /routes/<id> the <id> is an integer.

  • /mac should return either:

    • The MAC for the primary interface (document how you pick it), or
    • A list of all interface MACs (recommended and simpler to justify)

Concurrency

You may implement your server as single-threaded (one request at a time) or thread-per-connection. Either is accepted unless otherwise specified.

Difficulty Boundaries

You do not need to implement:

  • HTTPS
  • chunked encoding
  • keep-alive
  • full RFC compliance

Example Usage

from my_webserver import WebServer

server = WebServer()
server.serve()  # Starts the HTTP server

Tips

  • You may use socket and threading from the standard library.
  • Do not use Flask, FastAPI, or any third-party web frameworks.
  • You may use psutil or uuid for system info, but all route modifications must be in-memory only.
  • Focus on clean OOP design and code readability.

Deliverables

  • Your module file (e.g., my_webserver.py)
  • Example usage code (as above)
  • You may include a README or docstring explaining your design

Additional Requirements:

  • Your server should include proper error handling (module should raise excpetions, your server should catch exceptions, return appropriate error codes, do not crash on bad input).
  • Add basic logging (print/log each request, errors, and key server events).

This is a real-world style challenge! There are many valid solutions. Focus on OOP, HTTP parsing, and safe in-memory data handling.