After an Appium 3 upgrade, which /appium/... routes stop answering and what replaces them?

## What Appium 3 actually changed here Appium 2 was the architectural watershed: drivers and plugins became separately installed extensions and non-standard capabilities took the `appium:` vendor prefix. Appium 3 is the narrower follow-up, and its most visible piece is subtraction. A large block of the old `/session/:sessionId/appium/...` routes — the mobile-specific endpoints Appium carried from before the W3C specification settled — is gone from the server, and that work moved into per-driver execute methods invoked through `POST /session/:sessionId/execute/sync`. For a curling-club ladder suite written against the older surface the symptom is blunt: the session still starts, and then the step that used to reset the app or press a hardware key comes back as an unknown route. Nothing warned you at session creation, because none of this is negotiated there. ## The replacements that matter | Old route | Replacement | |---|---| | `POST .../appium/app/reset` | `mobile: clearApp` | | `POST .../appium/app/launch` | `mobile: launchApp` on XCUITest; `mobile: activateApp` or `mobile: startActivity` on the Android drivers | | `POST .../appium/app/close` | `mobile: terminateApp` | | `POST .../appium/app/background` | `mobile: backgroundApp` | | `POST .../appium/device/press_keycode` | `mobile: pressKey` on the Android drivers | | `POST .../appium/device/toggle_wifi`, `toggle_data`, `toggle_airplane_mode` | `mobile: setConnectivity` on the Android drivers | | `POST .../appium/device/network_speed` | `mobile: networkSpeed`, Android emulators only | | `POST /session/:sessionId/log` | `POST /session/:sessionId/se/log` | | `GET /sessions` | `GET /appium/sessions` | | `POST /session/:sessionId/execute` | `POST /session/:sessionId/execute/sync` | Two patterns run through that table, and both are the point of the change: - One old route often needs **two** replacements, because the replacement lives in a driver and drivers are per platform. Launching the ladder app is `mobile: launchApp` on the XCUITest driver for Apple platforms, and `mobile: activateApp` or `mobile: startActivity` on the Android drivers. The old endpoint hid a divergence the execute methods expose. - Some replacements are **narrower than the route they replace**. `mobile: networkSpeed` on the Android drivers is emulator-only, and `mobile: clearApp` is real on iOS but works on a simulator and throws on a real device. A green simulator run proves nothing about the device fleet. ## Removed is not the same as moved The migration guide marks a route *removed with a replacement* differently from a route *moved to the drivers*, and reading past that marker produces confident, wrong rewrites. Measured counter-examples worth knowing: - **Screen recording moved, it did not vanish.** Both the Android driver and the XCUITest driver re-add `POST .../appium/start_recording_screen` through their own method maps, un-deprecated, so it still answers on those drivers. The execute methods `mobile: startMediaProjectionRecording` on Android and `mobile: startXCTestScreenRecording` on iOS are the richer replacements, not the only way. - **The app-management endpoints survived.** `install_app`, `remove_app`, `app_installed`, `activate_app`, `terminate_app` and `app_state` are still declared in the core route table; the `mobile:` methods are the richer per-driver surface beside them. - **The keyboard endpoints survived.** `hide_keyboard` and `is_keyboard_shown` are still in the core route table. - **Legacy timeout parameters survived.** The guide says `POST /session/:sessionId/timeouts` no longer takes `type` and `ms`, but the core route still declares them as optional and the base implementation still handles that branch. The generalisation is the useful part: a driver can re-declare a route the core dropped, and a driver that proxies commands to an on-device agent can answer a route its own source barely mentions. Do not assert a removal you have not checked against the route tables. ## A migration that does not guess 1. **Inventory what the suite actually calls.** Grep for the old path segments and for the helper names your client wraps around them; a helper that still compiles tells you nothing about whether the server answers. 2. **Read the guide's markers, not just its list.** Separate *removed with a replacement* from *moved to the drivers* before touching code. 3. **Verify each supposed removal.** Check the core route table for endpoints the server still declares, and each driver's method map for routes it re-adds. 4. **Replace per platform, not once.** Expect the Android drivers and the XCUITest driver to need different names and different parameter maps for the same intent. 5. **Re-run against both fleets.** Gated replacements such as the emulator-only and simulator-only ones only show up when the run touches a real device. ## Why this is a senior question Because the naive version of the answer — "Appium 3 deleted the `/appium/` routes, rewrite everything as `mobile:` calls" — produces churn on endpoints that never went away and misses the divergence the real replacements introduce. The valuable behaviour is checking the route tables and the drivers' method maps before declaring anything gone, and planning the rewrite as a per-platform change rather than a search and replace.