REST API

리소스를 URI로 표현하고, 상태의 전송을 HTTP로 수행한다.

REST API의 핵심요소

리소스 (Resource)

GET /users
GET /posts/42

HTTP 메소드

• GET: 조회(Read) — 리소스를 가져온다

• POST: 생성(Create) — 새로운 리소스를 만든다

• PUT: 전체 수정(Update) — 리소스 전체를 덮어쓴다

• PATCH: 일부 수정(Update) — 리소스의 일부를 변경한다

• DELETE 삭제(Delete) — 리소스를 제거한다

// 새로운 사용자 리소스를 만든다.
POST /users

// 생성되어 있는 사용자 리소스를 조회한다
GET /users/1

표현 (Representation)

• 요청

POST /users
Content-Type: application/json

{
  "name": "Lucas",
  "email": "clee0627@gmail.com"
}

• 응답

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 1,
  "name": "Lucas",
  "email": "clee0627@gmail.com"
}

REST의 특징과 장점

• Server-Client 구조: 서버와 클라이언트로 이루어진 구조를 가지며 둘은 서로 독립적으로 개발될 수 있다. 이로 인해 시스템의 확장 및 변경이 용이하다.

• 인터페이스 일관성 (Uniform Interface): 요청의 의미는 HTTP 메서드/상태코드/하이퍼미디어로 일관되게 전달된다. API의 명확한 요청과 응답 구조 덕분에 개발자들이 API를 이해하고 사용하며 유지보수하기가 용이하다.

• 계층화 (Layered System): 클라이언트와 서버 간의 통신을 여러 계층으로 분리하여 클라이언트가 실제 서버를 직접 알지 못하게 한다. 이 과정에서 클라이언트는 중간 계층(캐시, 게이트웨이)이 있음을 신경 쓸 필요가 없으며 이를 통해 확장성, 유연성, 보안성을 높인다.

• 무상태 (Statetless): 서버는 클라이언트 상태를 유지하지 않으며 각 요청은 필요한 모든 정보를 담아야 한다. 상태를 서버가 기억할 필요가 없으므로 서버 확장성과 가용성이 좋다.

단점과 한계

RESTful

HATEOAS (Hypermedia As The Engine Of Application State)

HATEOAS 개념의 의도

• 클라이언트-서버 계약을 느슨하게 만든다 — 서버가 가능한 행동을 링크로 제공하면, 클라이언트는 URL 규칙을 하드코딩하지 않아도 된다.

• 서버 수정, 유지관리에 유리 — 서버가 링크 구조를 바꿔도 클라이언트는 응답에 포함된 링크만 따르면 된다.

• 사용자 흐름(워크플로우)을 명시 — 현재 상태에서 어떤 행동이 허용되는지, 어떤 관계(예: cancel, next, approve)가 있는지 표현 가능.

{
  "data": {
    "type": "articles",
    "id": "42",
    "attributes": {
      "title": "REST와 HATEOAS",
      "body": "..."
    }
  },
  "links": {
    "self": "/articles/42",
    "comments": "/articles/42/comments",
    "author": "/users/7"
  },
  "actions": {
    "edit": {
      "method": "PATCH",
      "href": "/articles/42",
      "title": "Edit this article"
    },
    "delete": {
      "method": "DELETE",
      "href": "/articles/42"
    }
  }
}