Cloud Seven

REST api, 단순함의 매력, 그리고 불편한 진실

HJ MOON's photo
HJ MOON
·

3 min read

REST API는 20여 년이 넘는 시간 동안 웹 개발의 중심축을 담당해왔습니다. 그 철학은 단순합니다: HTTP 프로토콜 위에서 자원을 CRUD(Create, Read, Update, Delete) 방식으로 다룬다. 그리고 이 단순함 덕분에 우리는 'RESTful'이라는 마법 같은 단어를 매일 사용하게 되었습니다. 그러나 이 단순함은 곧 우리를 매혹하는 동시에, 골칫덩어리로 만들기도 합니다.

1. REST는 단순하다는 환상

REST는 단순합니다. 아니, 최소한 그렇게 보입니다. GET, POST, PUT, DELETE만 잘 다루면 되니까요. 예를 들어, 다음과 같은 코드로 데이터를 생성하고 불러오면 모든 게 깔끔해 보입니다.

# POST로 데이터 생성
import requests

response = requests.post(
    "https://api.example.com/items",
    json={"name": "Example Item", "price": 100}
)
print(response.status_code)  # 201 Created
print(response.json())       # {"id": 1, "name": "Example Item", "price": 100}

# GET으로 데이터 가져오기
response = requests.get("https://api.example.com/items/1")
print(response.status_code)  # 200 OK
print(response.json())       # {"id": 1, "name": "Example Item", "price": 100}

하지만 여기서 끝일까요?
아니요. 문제는 단순함 속에 숨겨져 있는 복잡함입니다.

  • Pagination은 어떻게 처리할 것인가?

  • 필터링 쿼리 파라미터는 표준이 없는 상태로 난립하고 있다.

  • PUT vs PATCH: 언제 어떤 것을 써야 하는가?
    우리는 매번 이 논쟁 속에 갇힙니다. 결국 REST는 단순함 속에 복잡함을 숨기고 있을 뿐입니다.

2. REST의 표준은 누가 정했나?

"REST는 표준이다." 라는 말을 종종 들을 것입니다. 그러나 REST의 정의는 Roy Fielding의 논문에 있습니다. 이 논문 어디에도 JSON, HTTP 상태 코드, 그리고 URL 구조에 대한 상세한 표준은 없습니다. 결국 우리는 암묵적 합의와 'RESTful하다'는 느낌에 의존합니다.

다음과 같은 예를 보겠습니다:

# 사용자 정보를 PATCH로 수정
curl -X PATCH https://api.example.com/users/1 \
     -H "Content-Type: application/json" \
     -d '{"name": "Updated Name"}'

# HTTP 상태 코드 200을 반환하지만, 사실상 데이터베이스에 아무 변화가 없을 수도 있다.

RESTful API라면 당연히 상태 코드와 HTTP 메서드가 의미를 정확히 전달해야 하지만, 현실은 그렇지 않습니다. 204를 반환해야 할 상황에서 200이 나오고, PUT 요청인데 필드 일부만 수정되는 경우가 허다합니다. "RESTful"이라는 용어는 종종 설계 원칙보다는 마케팅에 가깝습니다.

3. REST API는 정말 오래 갈 수 있을까?

REST의 아키텍처는 2000년대 초반 웹 브라우저가 지배하던 시절의 유산입니다. 그러나 이제는 gRPC, GraphQL, WebSockets 같은 기술들이 REST의 단점을 보완하며 점차 채택되고 있습니다. 특히 GraphQL은 클라이언트가 원하는 데이터를 정확히 요청할 수 있다는 점에서 REST의 과잉 호출 문제를 해결합니다.

다음은 REST와 GraphQL의 요청 예시입니다:

REST

GET /users/1
GET /users/1/posts

GraphQL

query {
  user(id: 1) {
    id
    name
    posts {
      title
    }
  }
}

GraphQL에서는 한 번의 호출로 필요한 데이터만 가져올 수 있습니다. REST가 여전히 널리 쓰이지만, 시간이 지나면서 점차 "구식"으로 여겨질 가능성도 배제할 수 없습니다.

마치며: REST API의 미래를 생각하며

REST API는 단순함과 보편성을 무기로 웹 개발의 주류가 되었습니다. 그러나 그 단순함은 곧 한계로 작용하며, 현실의 복잡한 요구사항에 완벽히 부응하지 못합니다.

REST API는 분명 유용하지만, "RESTful하다"는 말에 매몰되지 말고 실제 사용 사례와 요구사항을 기반으로 기술을 선택해야 합니다. 종종 우리는 REST라는 단어 뒤에 숨은 복잡성을 간과하고, 그것이 제공하는 편리함에 취해버리곤 합니다.

결론적으로 REST는 도구일 뿐, 만능은 아닙니다. 그리고 도구는 필요에 따라 바뀌어야 합니다. 중요한 건 우리가 왜 이 도구를 사용하는지, 그리고 그것이 우리 프로젝트에 적합한지 끊임없이 고민하는 것입니다.

여러분의 REST API는 정말로 RESTful한가요?
아니면 단지 RESTful한 척하는 또 하나의 API일 뿐인가요?

restapi, HTTP