---
term: 'API REST'
seoTitle: '¿Qué es una API REST? Restricciones, Métodos, Códigos de Estado'
headline: '¿Qué es una API REST?'
slug: api-rest
category: api-realtime
shortDefinition: 'Una API REST es una API que sigue el estilo arquitectónico REST: recursos en URLs, solicitudes sin estado y métodos HTTP estándar.'
relatedTerms:
  - api
  - graphql-vs-rest
  - auto-generated-database-apis
  - crud-operations
contrastsWith:
  - graphql-vs-rest
aboutTerms:
  - 'REST (Representational State Transfer)'
  - 'API RESTful'
faq:
  - question: '¿Qué es una API REST en palabras simples?'
    answer: 'Una forma de que dos aplicaciones hablen sobre HTTP usando convenciones que todos ya conocen: cada cosa (un usuario, un pedido) vive en una URL, actúas sobre ella con un verbo estándar — GET para leer, POST para crear, PUT o PATCH para actualizar, DELETE para eliminar — y cada request se sostiene sola, llevando todo lo que el servidor necesita para responderla.'
  - question: '¿Qué significa REST?'
    answer: 'Representational State Transfer — transferencia de estado representacional — de la tesis doctoral de Roy Fielding del año 2000. El nombre describe el mecanismo: el servidor transfiere al cliente una representación del estado de un recurso (normalmente JSON), y el cliente mueve la aplicación de estado en estado a través de esas representaciones.'
  - question: '¿Cuál es la diferencia entre REST y RESTful?'
    answer: 'En el uso cotidiano, ninguna — los términos son intercambiables. Siendo pedantes, REST nombra el estilo arquitectónico y RESTful es el adjetivo para una API que lo implementa. La afirmación que circula de que "RESTful sigue todas las reglas y REST solo algunas" no tiene base alguna en el trabajo de Fielding.'
  - question: '¿Cuáles son las seis restricciones de REST?'
    answer: 'Separación cliente-servidor, ausencia de estado, cacheabilidad, interfaz uniforme, sistema en capas y — opcionalmente — código bajo demanda. La interfaz uniforme se despliega a su vez en cuatro reglas: recursos identificados por URIs, manipulación mediante representaciones, mensajes autodescriptivos e hipermedia como motor del estado de la aplicación.'
  - question: '¿Cuál es la diferencia entre PUT y POST?'
    answer: 'Idempotencia y direccionamiento. POST crea bajo una colección — el servidor asigna la URL, y repetir la solicitud crea duplicados. PUT escribe una representación completa en una URL conocida — repetirlo produce el mismo estado, lo que hace seguros los reintentos. Esa diferencia de seguridad, no el estilo, es la razón por la que la distinción importa.'
  - question: '¿Una API REST tiene que usar JSON?'
    answer: 'No. REST es agnóstico al formato — un recurso puede representarse como JSON, XML, HTML o una imagen, negociado mediante los headers Accept y Content-Type. JSON es simplemente el default moderno porque todo cliente lo parsea barato. La restricción trata de representaciones, no de una en particular.'
  - question: '¿Qué significa sin estado (stateless) en una API REST?'
    answer: 'Que el servidor no guarda memoria del cliente entre solicitudes: cada request lleva todo lo necesario para procesarla, incluidas credenciales como un bearer token. La recompensa es la escala horizontal — cualquier servidor puede responder cualquier request — y el costo son unos pocos bytes repetidos de contexto por llamada.'
  - question: '¿Qué es HATEOAS?'
    answer: 'Hypermedia As The Engine Of Application State: las respuestas incluyen enlaces a las acciones disponibles a continuación, de modo que los clientes navegan la API como las personas navegan la web — siguiendo enlaces en vez de codificar URLs a mano. Es la restricción menos implementada; la mayoría de las APIs "REST" de producción la omiten y viven felices en el nivel 2 del modelo de madurez.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Fielding dissertation, Chapter 5 — Representational State Transfer'
    url: 'https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'HTTP request methods — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods'
  - name: 'Richardson Maturity Model — Martin Fowler'
    url: 'https://martinfowler.com/articles/richardsonMaturityModel.html'
cta:
  title: 'Una API REST que no tienes que construir'
  text: 'Cada modelo de datos de Back4app se entrega como una API REST automáticamente — URLs de recursos, métodos y códigos de estado correctos, auth y permisos en la frontera — más SDKs que la envuelven de forma idiomática en cada plataforma.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-27'
translationKey: rest-api
---

**Una API REST es una API que sigue el estilo arquitectónico REST: recursos en URLs, solicitudes sin estado y métodos HTTP estándar.** REST — Representational State Transfer, definido en la [tesis](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) doctoral de Roy Fielding del año 2000 — es un estilo, no un protocolo ni un estándar: un conjunto de restricciones que, honradas en conjunto, producen APIs que toda la web ya sabe consumir, cachear y escalar.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| El modelo | Recursos en URLs · representaciones (normalmente JSON) · métodos estándar |
| La fuente | La tesis de Fielding del 2000, capítulo 5 — un estilo arquitectónico, no una spec |
| Las seis restricciones | Cliente-servidor · sin estado · cacheable · interfaz uniforme · en capas · código bajo demanda (opcional) |
| Los verbos | GET · POST · PUT · PATCH · DELETE — con semántica de seguridad e idempotencia |
| La nota honesta al pie | La mayoría de las APIs "REST" de producción son APIs HTTP de nivel 2 — y está bien |

## Un ciclo CRUD completo en HTTP crudo

Todo el estilo en cuatro solicitudes — esto es lo que cada framework y SDK termina enviando:

```text
POST /v1/posts                     →  201 Created            crear
{ "title": "Hello REST" }             Location: /v1/posts/8fk2

GET /v1/posts/8fk2                 →  200 OK                 leer
                                      { "title": "Hello REST", … }

PUT /v1/posts/8fk2                 →  200 OK                 reemplazar
{ "title": "Hello again" }            (PATCH actualizaría campos)

DELETE /v1/posts/8fk2              →  204 No Content         eliminar
GET /v1/posts/8fk2                 →  404 Not Found          …y ya no está
```

El mismo ciclo a través de SDKs que envuelven las llamadas REST:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The REST semantics, wrapped: create, read, update, delete
const post = new Parse.Object('Post');
post.set('title', 'Hello REST');
await post.save();                            // POST   /classes/Post      → 201

const fetched = await new Parse.Query('Post')
  .get(post.id);                              // GET    /classes/Post/:id  → 200

fetched.set('title', 'Hello again');
await fetched.save();                         // PUT    /classes/Post/:id  → 200

await fetched.destroy();                      // DELETE /classes/Post/:id  → 200
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The REST semantics, wrapped: create, read, update, delete
final post = ParseObject('Post')..set('title', 'Hello REST');
await post.save();          // POST   /classes/Post      → 201

await post.fetch();         // GET    /classes/Post/:id  → 200

post.set('title', 'Hello again');
await post.save();          // PUT    /classes/Post/:id  → 200

await post.delete();        // DELETE /classes/Post/:id  → 200
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The REST semantics, wrapped: create, read, update, delete
var post = Post()
post.title = "Hello REST"
let saved = try await post.save()      // POST   /classes/Post      → 201

let fetched = try await saved.fetch()  // GET    /classes/Post/:id  → 200

var updated = fetched
updated.title = "Hello again"
_ = try await updated.save()           // PUT    /classes/Post/:id  → 200

try await updated.delete()             // DELETE /classes/Post/:id  → 200
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The REST semantics, wrapped: create, read, update, delete
val post = ParseObject("Post")
post.put("title", "Hello REST")
post.save()                                    // POST   /classes/Post      → 201

val fetched = ParseQuery.getQuery<ParseObject>("Post")
    .get(post.objectId)                        // GET    /classes/Post/:id  → 200

fetched.put("title", "Hello again")
fetched.save()                                 // PUT    /classes/Post/:id  → 200

fetched.delete()                               // DELETE /classes/Post/:id  → 200
```

## Las seis restricciones de REST

1. **Cliente-servidor** — interfaz e implementación evolucionan de forma independiente; la UI nunca sabe cómo funciona el almacenamiento.
2. **Sin estado** — cada solicitud es autocontenida; el servidor no guarda sesión entre llamadas, que es lo que permite que cualquier réplica responda cualquier request.
3. **Cacheable** — las respuestas declaran su propia cacheabilidad; los GET con headers de caché correctos ponen toda la infraestructura de caché de la web (navegadores, [CDNs](/glossary/cdn-content-delivery-network/), proxies) a trabajar para tu API.
4. **Interfaz uniforme** — la restricción que *es* REST, en cuatro partes: recursos identificados por URIs; manipulación mediante representaciones (envías de vuelta el JSON en el que quieres que el recurso se convierta); mensajes autodescriptivos (método + headers dicen todo lo necesario para procesar la solicitud); e hipermedia como motor del estado de la aplicación (las respuestas enlazan las siguientes acciones).
5. **Sistema en capas** — los clientes no pueden saber si hablan con el origen, un caché o un gateway; los intermediarios se insertan con libertad.
6. **Código bajo demanda** *(opcional)* — los servidores pueden enviar código ejecutable a los clientes; la única restricción marcada como opcional, y la que la mayoría de las APIs ignora.

## Métodos HTTP: seguridad, idempotencia, CRUD

La tabla que falta en casi toda página de ranking — la semántica del [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110), condensada:

| Método | Rol CRUD | ¿Seguro? | ¿Idempotente? | ¿Reintentar a ciegas? |
| --- | --- | --- | --- | --- |
| GET | Leer | Sí | Sí | Sí |
| POST | Crear | No | **No** | No — puede duplicar |
| PUT | Reemplazar | No | Sí | Sí — mismo resultado |
| PATCH | Actualización parcial | No | No garantizado | Depende del diseño del patch |
| DELETE | Eliminar | No | Sí | Sí — sigue eliminado |

*Seguro* significa que la solicitud no cambia nada; *idempotente*, que repetirla no cambia nada más. Esto no es trivia — es la política de reintentos: un timeout de red en un PUT se puede reintentar sin miedo; el mismo timeout en un POST necesita una idempotency key o un chequeo de duplicados. El [mapeo CRUD](/glossary/crud-operations/) completo tiene su propia entrada.

## Códigos de estado: qué devolver y cuándo

| Situación | Devuelve |
| --- | --- |
| Lectura exitosa | 200 OK |
| Recurso creado | 201 Created + header `Location` |
| Eliminado; nada que decir | 204 No Content |
| Solicitud malformada | 400 Bad Request |
| Sin credenciales o inválidas | 401 Unauthorized |
| Autenticado pero sin permiso | 403 Forbidden |
| El recurso no existe | 404 Not Found |
| Superó el rate limit | 429 Too Many Requests ([detalles](/glossary/api-rate-limiting-throttling/)) |
| Falla del servidor | 500 Internal Server Error |

Las distinciones 401/403 y 200/201/204 son donde se nota la artesanía de una API: los códigos precisos hacen que los clientes puedan depurarse con nada más que la línea de estado.

## ¿Tu API es realmente REST? La escalera de madurez

La sección honesta que los explicadores comerciales omiten. El [Richardson Maturity Model](https://martinfowler.com/articles/richardsonMaturityModel.html) califica las APIs HTTP: nivel 0 (una URL, un verbo, RPC disfrazado), nivel 1 (recursos en URLs), nivel 2 (métodos y códigos de estado correctos), nivel 3 (hipermedia — HATEOAS).

```mermaid
flowchart TB
  accTitle: Richardson Maturity Model para APIs REST
  accDescr: Cuatro niveles desde el nivel cero, HTTP como simple túnel, pasando por recursos, luego verbos HTTP y códigos de estado, hasta el nivel tres con controles de hipermedia, con la mayoría de las APIs de producción viviendo en el nivel dos.
  L0["Nivel 0 — un endpoint, POST para todo (RPC disfrazado)"] --> L1["Nivel 1 — recursos: /posts/8fk2"]
  L1 --> L2["Nivel 2 — verbos + códigos de estado ← aquí vive la mayoría de las APIs de producción"]
  L2 --> L3["Nivel 3 — hipermedia: las respuestas enlazan las siguientes acciones (HATEOAS)"]
```

Por insistencia del propio Fielding, una API sin hipermedia no es REST — escribió un ensayo punzante diciendo exactamente eso. En la práctica, casi toda "API REST" aclamada es una API HTTP de nivel 2: recursos, verbos, códigos de estado, JSON, sin hipermedia. Esto importa menos como pureza y más como vocabulario — conocer la escalera te dice qué significa el término en una oferta de trabajo (nivel 2) versus en la tesis (nivel 3), y te salva tanto del HATEOAS de culto al cargamento como de las correcciones pedantes.

## REST vs. SOAP vs. GraphQL vs. gRPC

| | REST | SOAP | GraphQL | gRPC |
| --- | --- | --- | --- | --- |
| Naturaleza | Estilo arquitectónico | Protocolo | Lenguaje de consultas + runtime | Framework RPC |
| Cable | JSON sobre HTTP | Sobres XML | JSON sobre HTTP (un endpoint) | Protobuf sobre HTTP/2 |
| Contrato | OpenAPI (convención) | WSDL (obligatorio) | Schema (integrado) | .proto (obligatorio) |
| Caché | Nativo de HTTP — su superpoder | Pobre | A nivel de aplicación | A nivel de aplicación |
| Su fuerte | CRUD público de recursos | Formalidad enterprise/legacy | Datos anidados moldeados por el cliente | Velocidad entre servicios internos |
| Debilidad | Formas fijas que [over/underfetchean](/glossary/overfetching-underfetching/) | Verbosidad | Complejidad de caché y rate limits | Fricción en navegadores |

La [comparación con GraphQL](/glossary/graphql-vs-rest/) tiene una entrada completa propia.

## Convenciones que hacen agradable una API REST

Más allá de las restricciones, las convenciones con las que los consumidores te califican en silencio: **recursos con sustantivos en plural** (`/posts`, no `/getPost`); **anidar un nivel como máximo** (`/posts/8fk2/comments`, y ahí parar); **paginación en cada colección** — basada en cursores por profundidad y estabilidad, con límites aplicados; **filtrado y ordenamiento como parámetros de query**, no como variantes del endpoint; **versionado** con una política explícita (path `/v1/` o header — elige uno, publica ventanas de deprecación); **negociación de contenido** respetada (`Accept`, `Content-Type`); y **errores como JSON estructurado** con un código legible por máquinas, no solo prosa. Nada de esto está en la tesis; todo está en la diferencia entre una API que los desarrolladores recomiendan y una que soportan.

## Casos de uso comunes

- **APIs públicas y de socios** — la ubicuidad de REST es la funcionalidad: cada lenguaje, herramienta y desarrollador lo habla.
- **Backends de apps móviles y web** — el CRUD de recursos sobre HTTP calza con cómo la mayoría de las pantallas consume datos en realidad.
- **Costuras entre microservicios** — contratos internos donde el tooling de HTTP (gateways, tracing, caché) se gana su lugar.
- **Integraciones estilo webhook** — sistemas notificando a sistemas con llamadas HTTP simples que ambos lados ya entienden.
- **APIs de datos autogeneradas** — plataformas que [exponen una base de datos como recursos REST](/glossary/es/apis-generadas-automaticamente/) — la ruta más rápida del esquema a una API funcionando.

## ¿Deberías usar REST? Matriz de decisión

| REST es el default correcto cuando… | Busca otra cosa cuando… |
| --- | --- |
| API pública, consumidores desconocidos | Malla interna de alto throughput → gRPC |
| Dominio CRUD con forma de recursos | Los clientes necesitan moldear respuestas anidadas → GraphQL |
| El caché HTTP puede cargar las lecturas | Push bidireccional en tiempo real → [WebSockets](/glossary/websockets-real-time-sync/) / [live queries](/glossary/real-time-live-queries/) |
| La simplicidad y la amplitud del tooling importan | Se exigen contratos enterprise formales → SOAP |
| Las pantallas mapean limpio a recursos | Una pantalla agrega cinco servicios → endpoint compuesto / BFF |

## Limitaciones y trade-offs

- **Las representaciones fijas no les quedan a clientes diversos.** El par overfetching/underfetching es la debilidad estructural de REST; los sparse fieldsets y los parámetros de expansión mitigan, GraphQL rediseña.
- **No hay contrato obligatorio.** Nada fuerza una spec OpenAPI, así que muchas APIs REST están documentadas por folklore; la disciplina es opcional donde gRPC y GraphQL la hacen estructural.
- **La ausencia de estado repite contexto.** La auth y el contexto de tenant viajan en cada solicitud — barato en bytes, pero empuja la semántica de sesión a los tokens y vuelve incómodos algunos flujos (transacciones de varios pasos).
- **La tentación del N+1 por diseño.** Pensar en recurso-por-URL invita a [clientes de una-llamada-por-ítem](/glossary/n-plus-one-query-problem/); las buenas APIs entregan expansión y batch antes de que los consumidores improvisen loops.
- **La palabra "REST" es ambigua.** API HTTP de nivel 2 en la mayoría de las bocas, arquitectura de hipermedia en la tesis — lee cuál de las dos quiere decir una spec, una oferta de trabajo o un revisor antes de discutir.

## APIs REST en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La API REST aquí se genera, no se construye: cada clase de tu modelo de datos es de inmediato un recurso — `POST /classes/Post` crea, `GET /classes/Post/:id` lee, con los métodos, los códigos de estado y la semántica de `Location` del recorrido de arriba — detrás de keys, tokens de usuario y permisos a nivel de clase haciendo cumplir la frontera. Los code tabs muestran el mismo ciclo a través de los SDKs, que son envoltorios idiomáticos delgados sobre exactamente este HTTP; cuando una operación crece más allá del CRUD, una función de Cloud Code agrega un endpoint personalizado en un archivo. REST de nivel 2, correcto por defecto, del esquema a la URL en lo que tardas en definir la clase.