{"id":46666,"date":"2023-03-08T10:24:06","date_gmt":"2023-03-08T10:24:06","guid":{"rendered":"https:\/\/www.arimetrics.com\/glosario-digital\/api-rest"},"modified":"2026-10-01T08:58:49","modified_gmt":"2026-10-01T08:58:49","slug":"api-rest","status":"publish","type":"encyclopedia","link":"https:\/\/www.arimetrics.com\/en\/digital-glossary\/api-rest","title":{"rendered":"Api REST"},"content":{"rendered":"<p><strong>Definition:<img decoding=\"async\" class=\"boxpad alignright wp-image-46622 size-full\" src=\"https:\/\/www.arimetrics.com\/wp-content\/uploads\/2023\/03\/api-rest.jpg\" alt=\"REST API\" width=\"300\" height=\"300\" srcset=\"https:\/\/www.arimetrics.com\/wp-content\/uploads\/2023\/03\/api-rest.jpg 300w, https:\/\/www.arimetrics.com\/wp-content\/uploads\/2023\/03\/api-rest-150x150.jpg 150w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/strong><\/p>\n<p>A <strong>REST API<\/strong> is an application programming interface designed according to the principles of the REST architectural style, usually over HTTP. It exposes resources through identifiers and allows a client to retrieve or modify their representations through operations with defined semantics.<\/p>\n<p>REST is not a protocol and does not require JSON. It is an <strong>architectural style<\/strong> with specific constraints for distributed systems. An API may use HTTP and return JSON without satisfying all those constraints; it may therefore be an HTTP API without being a complete REST implementation.<\/p>\n\n<h2>What a REST API is used for<\/h2>\n<p>A REST API enables different applications to exchange information through an <strong>agreed interface<\/strong>. A website, mobile application or internal system can request data and perform operations without knowing how the server&#8217;s storage or business logic is implemented.<\/p>\n<p>This approach can connect a user interface to its backend, integrate platforms, publish controlled data or coordinate services. The <a href=\"https:\/\/www.arimetrics.com\/en\/digital-glossary\/api\">API<\/a> defines which resources and operations are available, while <strong>each consumer<\/strong> decides how to incorporate them into its process.<\/p>\n<p>Separating the client from the server allows them to evolve independently, but it does not remove design work. <strong>Practical compatibility<\/strong> depends on stable contracts, documentation, error handling and change management. REST alone does not guarantee speed, scalability or security.<\/p>\n<h2>How a REST API works<\/h2>\n<p>The client sends an <strong>HTTP request<\/strong> to a <a href=\"https:\/\/www.arimetrics.com\/en\/digital-glossary\/url\">URL<\/a> that identifies a resource. The request includes a method, headers and, where appropriate, a body. The server processes the operation and returns a response containing a status code, headers and a representation of the resource.<\/p>\n<p>REST APIs commonly use <a href=\"https:\/\/www.arimetrics.com\/en\/digital-glossary\/http\">HTTP<\/a> and follow the semantics of its methods:<\/p>\n<ul>\n<li><strong>GET:<\/strong> Retrieves a representation without requesting a change to the resource.<\/li>\n<li><strong>POST:<\/strong> Sends data for the server to process or to create a subordinate resource.<\/li>\n<li><strong>PUT:<\/strong> Creates or replaces the state of a resource at the specified address.<\/li>\n<li><strong>PATCH:<\/strong> Requests a partial modification of the resource.<\/li>\n<li><strong>DELETE:<\/strong> Requests removal of the identified association or resource.<\/li>\n<\/ul>\n<p>The body may use <a href=\"https:\/\/www.arimetrics.com\/en\/digital-glossary\/json\">JSON<\/a>, XML, text or another <strong>agreed format<\/strong>. The `Content-Type` and `Accept` headers help describe or negotiate the representation. The 2xx, 4xx and 5xx status code classes report the result, but their precise use should respect HTTP semantics.<\/p>\n<h2>Constraints of the REST style<\/h2>\n<p>Roy Fielding described REST as a set of <a href=\"https:\/\/ics.uci.edu\/~fielding\/pubs\/dissertation\/rest_arch_style.htm\" target=\"_blank\" rel=\"noopener\">architectural constraints<\/a>. They are not optional features added to an API; they are properties that determine how its components interact.<\/p>\n<p>The main constraints are:<\/p>\n<ul>\n<li><strong>Client and server:<\/strong> Interface responsibilities are separated from storage and processing responsibilities.<\/li>\n<li><strong>Statelessness:<\/strong> Each request contains the information needed to understand it; the server does not depend on an earlier conversational session.<\/li>\n<li><strong>Cacheable responses:<\/strong> Responses state whether they can be reused to avoid unnecessary equivalent requests.<\/li>\n<li><strong>Uniform interface:<\/strong> Resources have stable identifiers and are manipulated through representations and self-descriptive messages.<\/li>\n<li><strong>Layered system:<\/strong> A client may communicate through intermediaries without knowing the complete infrastructure.<\/li>\n<li><strong>Code on demand:<\/strong> Optionally, a server may temporarily extend a client by transferring executable code.<\/li>\n<\/ul>\n<p>The uniform interface also includes hypermedia as the engine of application state. Many APIs described as REST do not implement this element fully, so <strong>RESTful<\/strong> should indicate a degree of conformance with the style rather than acting as an automatic synonym for every web API.<\/p>\n<h2>Designing resources and operations<\/h2>\n<p>A REST API is organized around <strong>identifiable resources<\/strong>, such as customers, orders or documents. Paths generally use nouns representing those resources, while the HTTP method expresses the operation. This avoids encoding actions that conflict with method semantics inside the URL.<\/p>\n<p>The design should consider these properties:<\/p>\n<ul>\n<li><strong>Method safety:<\/strong> GET and HEAD are defined as safe because they do not request a change to server state.<\/li>\n<li><strong>Idempotency:<\/strong> Repeating PUT or DELETE with the same intent should have the same final effect as performing it once.<\/li>\n<li><strong>Consistent status codes:<\/strong> Each response should distinguish successful results, client errors and server failures.<\/li>\n<li><strong>Pagination and filters:<\/strong> Large collections need explicit limits and criteria to prevent uncontrolled responses.<\/li>\n<li><strong>Compatible evolution:<\/strong> Changes to fields, paths or behaviour require a versioning and retirement strategy.<\/li>\n<\/ul>\n<p><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc9110.html\" target=\"_blank\" rel=\"noopener\">HTTP semantics<\/a> define the meaning of methods and status codes. Precise documentation should add parameters, schemas, examples, limits and error formats so the <strong>public contract<\/strong> can be consumed and tested consistently.<\/p>\n<h2>Security and limitations of a REST API<\/h2>\n<p>REST does not provide secure communication automatically. Protection depends on HTTPS, identity authentication, permission checks, input validation and abuse controls. Authentication establishes who is making a request; <strong>authorization<\/strong> determines which resources and actions that identity may use.<\/p>\n<p>A system may use <strong>different mechanisms<\/strong>, such as API keys, sessions, certificates or <a href=\"https:\/\/www.arimetrics.com\/en\/digital-glossary\/oauth\">OAuth<\/a>, depending on the context. OAuth delegates access, but it does not replace encryption, validation or object-level authorization checks.<\/p>\n<p>Systems should also set size and rate limits, record relevant failures, avoid exposing unnecessary data and return errors that do not disclose sensitive information. Caching needs careful configuration when responses contain private data. A well-designed REST API combines architectural constraints with <strong>operational controls<\/strong>, testing and continuous monitoring.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Definition: A REST API is an application programming interface designed according to the principles of the REST architectural style, usually over HTTP. It exposes resources through identifiers and allows a client to retrieve or modify their representations through operations with defined semantics. REST is not a protocol and does not require JSON. It is an [&hellip;]<\/p>\n","protected":false},"author":28,"featured_media":0,"template":"","encyclopedia-tag":[1275],"class_list":["post-46666","encyclopedia","type-encyclopedia","status-publish","hentry","encyclopedia-tag-data-exchange"],"_links":{"self":[{"href":"https:\/\/www.arimetrics.com\/en\/wp-json\/wp\/v2\/encyclopedia\/46666","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.arimetrics.com\/en\/wp-json\/wp\/v2\/encyclopedia"}],"about":[{"href":"https:\/\/www.arimetrics.com\/en\/wp-json\/wp\/v2\/types\/encyclopedia"}],"author":[{"embeddable":true,"href":"https:\/\/www.arimetrics.com\/en\/wp-json\/wp\/v2\/users\/28"}],"wp:attachment":[{"href":"https:\/\/www.arimetrics.com\/en\/wp-json\/wp\/v2\/media?parent=46666"}],"wp:term":[{"taxonomy":"encyclopedia-tag","embeddable":true,"href":"https:\/\/www.arimetrics.com\/en\/wp-json\/wp\/v2\/encyclopedia-tag?post=46666"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}