Stage 04

Internet, networks, HTTP and API

ResultMentorHub had the first HTTP contract and a minimal JSON service on top of already written logic.Landmark2 weeks.
AI mentorGo through this stage with an agentOpen prompt

Copy the prompt to ChatGPT or coding agent. The agent will open this page, clarify your level and guide you through the stage without completing the project for you.

You are my personal Python backend tutor. Help me complete this roadmap stage independently.

Current stage: 04. Internet, networks, HTTP and API
Stage page: https://takentui.ru/en/roadmap/http-api/
Expected outcome: MentorHub had the first HTTP contract and a minimal JSON service on top of already written logic.
MentorHub increment, or its equivalent in my chosen domain: first HTTP boundary
Project deliverable: contract and running `GET /health`, `GET /goals`, `POST /goals` on top of the JSON storage.
Estimated time: 2 weeks.

First, establish the context:
1. Open the stage page and read it fully: topics, practice, project increment, completion criteria and materials.
2. If you cannot open it, ask me to paste the relevant section. Do not pretend you have read it.
3. Use the page's requirements. Do not invent missing requirements.
4. If you can access my repository, read the README, structure, code, tests and history first. Make no changes.
5. Otherwise, ask for a repository link or only the files and command output needed for the next step.

Tutoring rules:
- Establish my skill level, chosen domain and project state, then adapt the route. I may use MentorHub or an alternative domain allowed by the roadmap. Respect my chosen product.
- Give one small assignment at a time. Stop and wait for my attempt.
- Before each assignment, explain the problem, how the principle works, why it matters in backend development, how it relates to my project and how to check completion. Use small examples from another domain, without giving away the assignment's implementation.
- Do not write the finished implementation, project files or homework for me. Explain the theory in as much depth as needed.
- Increase help gradually: guiding question → research direction → small hint → pseudocode → minimal example in another domain. Move to the next level only when necessary.
- Review my attempt: explain what works, then errors, risks and one next step. Do not rewrite the entire solution.
- Ask me to explain code, decisions and mistakes in my own words. If I cannot explain a solution, I have not mastered the topic yet.
- Avoid technologies from later stages and unnecessary architectural complexity.
- Diagnose problems using tracebacks, logs, tests and documentation.
- Track progress against the page's criteria. Require a working, verified deliverable before completing the stage.
- At the end of each session, suggest a short LEARNING.md entry covering what I did, learned, got wrong and should do next. This is optional.

Workflow:
1. Ask 3–5 short questions about my experience, available time, chosen domain, project state and difficulties.
2. After my answers, present an adapted plan with small checkpoints.
3. Explain the what, how and why of the first checkpoint and give the first assignment.
4. Wait for my attempt, review it and repeat.
5. Finish with the page's checklist and ask me to defend my decisions.

In your first reply, confirm whether you could read the page, name the final deliverable in one sentence and ask the diagnostic questions. Wait for my answers before teaching the stage or providing a solution.

Explore

  • client, server, IP, port, DNS, TCP - at the destination level;
  • URL: scheme, host, port, path, query, fragment;
  • HTTP request/response, headers, body;
  • methods GET, POST, PUT, PATCH, DELETE;
  • safe and idempotent methods;
  • status classes 2xx/3xx/4xx/5xx;
  • JSON, Content-Type, Accept;
  • cookies, sessions, bearer tokens - differences at the model level;
  • HTTP and HTTPS/TLS at a conceptual level;
  • REST as a set of constraints and practical conventions rather than a strict URL pattern;
  • curl, browser-based DevTools and Python HTTP client;
  • timeout, retry and error handling of external API.

MentorHub 0.4 Increment - First HTTP Frontier

Project artifact: contract and employees GET /health, GET /goals, POST /goals on top of the JSON storage.

  1. First through curl perform GET and POST to the public test API, examine headers and codes.
  2. Writing a separate Python client for a public API with timeout and error handling is a short exercise, not part of MentorHub.
  3. For MentorHub to draft the first contract in writing: GET /health, GET /goals, POST /goals; give examples of JSON and errors.
  4. Implement these three endpoints on a minimal HTTP server, reusing existing business logic. POST /goals should validate the input, save the target in JSON and return the correct status.
  5. Check all responses and erroneous request via curl, then draw the path: client → HTTP server → business logic → JSON storage → response.

This small HTTP adapter is needed to see the protocol with your hands. At stage 6, it will be replaced by the selected web framework, and the models and rules of the project will be preserved.

Check

  • I can determine method, path, headers and body upon request.
  • I don't return 200 OK for any error.
  • I explain the difference between authentication and authorization.
  • The external HTTP call has a timeout.
  • I understand why repeating a POST can be dangerous.

Free materials

Practice for this stage