When you're wiring up an API, the slow part isn't the code — it's the context-switch to Postman or a curl in another window, then back. LingCode's REST Client tab puts a full HTTP client in the bottom panel, next to your code and your terminal. You build a request, send it, and read the response in the same window you're editing in. This walks through the whole tab so you know what every control does.
Open it from the bottom panel: click the REST Client tab (the globe-style "network" icon). If you're not sure how the bottom panel is laid out, the bottom panel overview covers all nine tabs first.
Across the top are three controls. The method picker on the left is a dropdown with GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS — each color-coded (GET green, POST blue, PUT orange, PATCH yellow, DELETE red, HEAD purple, OPTIONS gray) so you can tell at a glance what a request does. Next to it is the URL field (placeholder https://api.example.com/endpoint). On the right is the Send button — it's disabled while the URL is empty, and while a request is in flight it shows a spinner instead of the "Send" label so you know it's working.
Leave the method on GET, paste a real URL — try a public one like https://api.github.com/repos/anthropics/anthropic-sdk-python — and click Send. The right-hand pane fills in. Before you send anything it shows a placeholder ("Send a request to see the response"); after a response arrives you get a status bar with four facts:
200 OK).Below the status bar, a small picker switches the response between Body (the raw response text, monospaced and selectable) and Headers (every response header, sorted alphabetically, key in the accent color and value beside it). If the request fails outright — bad host, no network — you get a warning icon and the error message instead of a status bar.
The left side of the request body has two tabs: Headers and Body. On the Headers tab, each header is a row with four parts: a checkbox to enable or disable that header without deleting it, a Key field, a Value field, and a minus button to remove the row. Click Add Header at the bottom to add a blank row.
For an authenticated request, add a row with key Authorization and value Bearer <your-token>. The enable checkbox is handy when you're debugging: toggle a header off, re-send, and see whether it was the cause — no need to retype it.
Switch the method to POST, then click the Body tab. There's a body-type picker; with the type set to None the editor just shows "No body". Choose a content type and a monospaced editor appears — paste your raw JSON there, for example:
{
"name": "widget",
"quantity": 3
}Add a Content-Type: application/json header on the Headers tab so the server parses it, then click Send. The response pane updates exactly as it did for the GET — status, timing, size, body, headers.
curl for iterating. The Headers tab's enable/disable checkboxes and the persistent Body editor mean you tweak one thing and re-send, rather than editing a long shell line and re-escaping quotes every time. And the response is parsed for you — status color, timing, and size are right there instead of buried in -v output.
Once you've sent at least one request, a History bar appears along the bottom of the tab — a horizontal row of pills for your last 10 requests. Each pill shows the method (color-coded) and a shortened URL. Click a pill to load that request — method, URL, and all — back into the editor so you can re-send or tweak it. It's the quickest way to bounce between two endpoints you're comparing.
Authorization header you type in is part of that request and its history, not stored in Keychain like your provider keys. Use short-lived or scoped tokens for testing, and don't paste long-lived production secrets you wouldn't want sitting in the history bar.