Build Basics / Standard term
Request and response
The back-and-forth where one piece of software sends a request asking a server for something, and the server sends a response with the answer. This single exchange sits behind every page load and data call.
A request and response is the back-and-forth where one piece of software sends a request asking a server for something, and the server sends a response with the answer. The request names what you want and carries any details the server needs; the response carries the result plus a status code that says whether it worked. Picture a password reset: your browser sends a request that says "reset the password for this account," the server checks the account and emails a reset link, then sends back a response confirming the request was accepted. Every click that loads new content is one of these round trips, usually finished in a fraction of a second.
Builder example
When you wire an AI assistant to a tool, you are asking it to send a request and read the response. If you tell the agent to fetch open to-do items and the response comes back with an error status instead of data, the agent needs to see that status to retry or report the problem rather than inventing items. Designing each call so the response is checked, not assumed successful, is what keeps an automated flow honest.
Common confusion: A response always comes back, even when the request fails. A status code in the response says whether the server succeeded, was denied, or hit an error, so receiving a response does not mean the action worked. Read the status before trusting the contents.