In Appium, which request reads one attribute from an element on Android and iOS?

## The request itself Every attribute read in Appium goes through one request: ```http GET /session/:sessionId/element/:elementId/attribute/:name ``` Three things go into it and one thing comes back. - `:sessionId` — the session the client created, which fixes the device and the driver answering. - `:elementId` — an opaque identifier a previous find returned. You never construct one; you receive it and pass it back. - `:name` — **exactly one** attribute name. There is no plural form of this request, so three facts about one element are three calls. The reply is the value stored under that name, as JSON. If the element carries no such attribute, the reply is empty rather than an error. ## The shape is shared; the vocabulary is not A milk-round delivery app's *skip tomorrow* switch is the standard example. The Android session and the iOS session make the *same* request against the *same* endpoint, and get their answers from different names: | | Android — UiAutomator2 driver | iOS — XCUITest driver | | --- | --- | --- | | Endpoint | `/session/:sessionId/element/:elementId/attribute/:name` | identical | | Names available here | `checked`, `enabled`, `displayed`, `bounds` | `value`, `label`, `visible`, `hittable` | | Switch is on | `checked` reads `true` | `value` reads `1` | That asymmetry is the whole reason this is worth learning as a junior. It is tempting to conclude from *the request is the same* that *the code is the same*, and it is not. The request is protocol; the names are platform. ## What the reply is, and what it is not - It is **one value**, for **one element**, under **one name**. - It arrives as JSON and most often as text, so `true` and `1` come back as strings that need turning into a boolean before an assertion reads them. - An empty reply means the element does not carry that name on that driver. It does **not** mean the attribute is false, and it does not raise an error you would notice in a log skim. - It is a snapshot of the moment the driver answered. Nothing about the read waits for anything, and nothing about it promises the screen has stopped moving. That third bullet is the one that catches people. Send Android's `checked` to an iOS session and you get an empty result, and code that treats empty as false reports every switch as off. The test still runs, still reports, and is now lying in one direction. ## Where the element identifier comes from The attribute read is always the *second* step. Something has to have matched an element first, and the identifier that comes back from that match is what makes the attribute call addressable. Two practical consequences follow: 1. An identifier belongs to its session. It is not a durable handle you can store between runs, and it is meaningless in another session. 2. If the screen changes underneath you, the identifier can stop referring to anything usable, and the attribute read is where you find out. ## A habit worth forming early 1. Write the platform next to the attribute name, in the code, every time — a bare `checked` in a shared helper tells the next reader nothing about which driver answers it. 2. Normalise the reply on the line that reads it, so no raw attribute string reaches an assertion. 3. Treat an empty reply as a bug in your mapping rather than as a false value, and fail loudly on it. 4. Count your reads. Three attributes across forty rows is a hundred and twenty round trips, and the endpoint gives you no way to batch them. ## Why the endpoint being shared still helps None of this makes the shared shape useless. Because both drivers answer the same request in the same way, everything *around* the read is portable: the client call, the error handling, the retry decision, the logging, the place in your code where the value is normalised. Only the name and the expected token change. A well-built helper therefore has exactly one platform-dependent line in it, and a badly built one has the platform difference smeared across every test that reads state. The short version to carry into an interview: one endpoint, one name per call, an element identifier from a prior find, a JSON value back, an empty reply when the name does not exist on that platform — and two vocabularies that overlap in nothing.