Get
'''Get''' or '''GET''' may refer to:- the English verb [[get]], meaning to obtain or receive
- {{Interproject link|wikt|get}} (Georgian letter)
Technology
HTTP GET
The HTTP GET method is one of the primary request methods in the Hypertext Transfer Protocol (HTTP), designed to request and retrieve a representation of a resource identified by a specific uniform resource identifier (URI).[1] It serves as the fundamental mechanism for information retrieval on the web, transferring data without altering the server's state.[2] In operation, the GET method appends any required parameters to the URI as a query string, such as?key=value, which the server uses to generate the appropriate response. This approach ensures the method is both safe—meaning it has no expected side effects on the server beyond retrieval, such as modifying resources—and idempotent, where multiple identical requests produce the same result as a single request, facilitating safe retries and caching.[3][4] For instance, a conditional GET can include an If-Modified-Since header to check if the resource has changed since a specified date, returning a 304 Not Modified status if unchanged to optimize bandwidth.[5]
Common use cases for HTTP GET include fetching web pages, querying application programming interfaces (APIs) for data retrieval, and submitting search forms where parameters like keywords are encoded in the URI. It is particularly suited for read-only operations, such as loading a user's profile from /api/user?id=123 or retrieving search results via /search?q=example.[2]
The GET method was introduced in HTTP/1.0 and formally standardized in RFC 1945, published in May 1996, which defined it as a means to retrieve entities without side effects.[1] Its semantics evolved in subsequent specifications, including HTTP/1.1's RFC 7231 from 2014, which clarified its safe and idempotent properties while emphasizing cacheability for responses.[6]
Limitations of GET include practical restrictions on URI length, typically around 2048 characters imposed by browsers and servers, beyond which requests may fail.[7] Additionally, since parameters are visible in the URI, GET is unsuitable for transmitting sensitive data, such as passwords, due to potential logging in proxies, browsers, and servers.
In comparison to the POST method, GET transmits data via the URI query string rather than the request body, making it more bookmarkable and shareable but less secure for private information.[8] POST, by contrast, is neither safe nor idempotent, as it can modify server state, and its responses are not cacheable by default, whereas GET supports efficient caching to reduce network load.[3][4]
RCS co command
The Revision Control System (RCS) is an early version control system developed in the 1980s to manage revisions of text files, such as source code and documentation, by storing them in a compact delta-based format. The primary command for retrieving a revision from an RCS file isco (short for checkout), which extracts the specified or default revision into a corresponding working file for viewing or editing.[9] This command is central to RCS workflows, enabling users to access historical versions without duplicating full file contents.[10]
RCS was created by Walter F. Tichy in 1982 at Purdue University as an improvement over earlier systems like SCCS, emphasizing efficiency in storage and retrieval through delta encoding, where only changes (differences) between revisions are saved.[11] The full text of the latest trunk revision is stored directly, while prior revisions use reverse deltas (backward differences) for reconstruction, and branch revisions employ forward deltas; this approach minimizes disk space and speeds up operations, with retrieval times proportional to the size of the applied deltas rather than the full file.[9] RCS quickly integrated into Unix environments, becoming a standard tool for software development by the mid-1980s.[12]
The syntax for the co command is co [options] file, where file refers to the RCS file (typically named file,v in a subdirectory like RCS/, but specified without the extension). Key options include -r[rev] to select a specific revision (defaulting to the latest on the trunk if omitted), -l[rev] to check out and lock the revision (preventing others from modifying it), -u[rev] to unlock a previously locked revision, and -p[rev] to output the revision to standard output without creating a working file.[10] Locking with -l or -e (for strict editing mode, which also removes the working file if already present) supports controlled editing workflows, ensuring changes are checked in via the ci command to create new revisions.[9]
In practice, the co command reconstructs the revision by applying deltas sequentially from the stored RCS file, expanding embedded keywords like $Id$ or $Revision$ with current values during retrieval. For basic use, running co file.c retrieves and writes the latest revision to file.c, overwriting any existing working copy unless locked.[10] To access an older revision, such as 1.3, the command co -r1.3 file.c produces a read-only working file; combining with locking yields co -l -r1.3 file.c for editable checkout of that version. A common workflow involves checking out with lock (co -l file.c), editing the file, then checking in (ci -m"update description" file.c) to append a new delta-based revision.[9]
As a foundational tool, RCS directly influenced subsequent systems, serving as the predecessor to the Concurrent Versions System (CVS), which extended RCS's delta storage and file format for networked, multi-user collaboration while retaining compatible history files.[13] The checkout-based retrieval model in RCS also conceptually underpins mechanisms in modern tools like Git, where commands such as git checkout enable switching between versions or branches.[14]