[Seminar2] What is RESTful?

[Jang99u]

본인이 생각하는 RESTful 을 정의해보고 클라이언트가 좋아할만한 API path를 고민해보세요.

L4 Switch, L7 Switch 가 무엇인지 조사해보세요.

• L4 Switch
  • 역할: 주로 IP 주소와 포트 번호 기반으로 트래픽을 분산. TCP/UDP 수준에서 동작합니다.
  • 알 수 있는 정보: 송수신 IP 주소, 포트 번호 등 전송 계층의 정보를 바탕으로 트래픽을 제어합니다.
  • 비용: 상대적으로 L7 스위치보다 저렴합니다.
• L7 Switch
  • 역할: 애플리케이션 계층에서 동작하며 HTTP 헤더, URL, 쿠키 등의 데이터를 기반으로 더 세부적인 트래픽 제어를 수행합니다.
  • 알 수 있는 정보: 애플리케이션 데이터, URL, 쿠키, HTTP 메서드 등
  • 비용: L4 스위치에 비해 고급 기능을 제공하므로 비용이 더 높습니다.

REST vs RESTful

• REST

  • REST는 아키텍처 스타일 또는 설계 원칙
  • 자원 / 행위 / 표현 으로 구성되어 있습니다.
  • 자원 : 모든 자원에는 고유한 ID가 존재하고 이 자원은 서버에 존재합니다. ID는 URI 형태입니다.
  • 행위 : HTTP 프로토콜 메서드를 사용합니다.
  • 표현 : 서버와 클라이언트는 JSON / XML 등을 통해 데이터를 주고 받습니다.

• RESTful

  • REST 원칙을 따르는 웹 서비스를 설명하는 데 사용됩니다.
  • RESTful은 REST 원칙을 실제로 구현한 웹 서비스를 말합니다.

내가 생각하는 RESTful과 클라이언트가 좋아할만한 API path

결국에 제가 생각하는 RESTful은 서버와 클라이언트간의 소통을 정의하는 중요한 수단인 것 같습니다.

서버 개발자로서 API 명세서를 작성하는 일은 결국 우리는 이런 경로(자원)로 어떤 요청(행위)을 보내면 DB에 있는 관련된 데이터들을 특정한 Response 형태(표현)로 줄거야 라는 말이 아닐까..? 생각됩니다.

이에 더해 클라이언트로 하여금 보다 쉽게 요청을 보낼 수 있게 해주는 핵심이 자원 / 행위 / 표현 이기 때문에 REST는 이렇게 3개로 구성된다 하는게 아닐까 생각됩니다.

클라이언트 개발자 입장에서는 어떤 Path로 어떤 요청을 보냈을 때, 어떤 형식의 응답이 오는지가 가장 중요합니다. 서버 내에서의 비즈니스 로직이 어떻게 돌아가고 DB에서 얼마나 효율적으로 값을 가져오는지는 전혀 중요하지 않을 것입니다. 즉, 어떤 자원에 어떤 행위를 했을 때 어떤 표현이 돌아오냐 만이 중요한 것이라 생각됩니다.

클라이언트에서 POST 요청을 보낸다고 꼭 DB상에 어떤 튜플을 생성해야 되는 것은 아닙니다. POST 요청을 보냈을 때 삭제할 수도 있습니다. 다만, 이런 것은 RESTful 하지 않을 것입니다. 클라이언트와 서버간 알맞은 소통을 위해 만든 설계 원칙이 REST인데 POST 요청이 들어왔을 때 무언가를 삭제한다면 이는 알맞은 소통이 아니기 때문입니다.

따라서 우리가 적절한 API Path를 만들어주는 것 역시 REST를 지킨다 할 수 있을 것 같습니다. 만약 클라이언트가 DB 내부에 있는 다이어리를 단 하나만 요청한다고 하면, 이 때의 API Path는 /diaries 보다는 /diary 가 자연스러울 것입니다.

이 역시 마찬가지로 API Path를 /diaries 로 해주던 /diary 로 해주던 같은 비즈니스 로직을 거쳐 같은 값을 반환해준다면 결과 자체는 동일할 것입니다. 하지만, 클라이언트가 다이어리 단 하나만을 요청했는데 우리가 설정해둔 API Path가 /diaries 라면, 역시 적절한 소통은 아닐 것입니다. 아무것도 모르는 클라이언트 개발자가 와서 이를 본다면 요청에 대한 응답이 제대로 온 것인지 아닌지 알 수가 없을 것입니다.

따라서 REST는 단순한 아키텍처 스타일 또는 설계 원칙이라기 보다는, 서버와 클라이언트간의 원할한 소통을 위한 설계 원칙 이라는 표현이 조금 더 적절할 것 같습니다. 우리가 흔히 생각하는 API Path의 규칙인 단수형과 복수형의 구분 등은 결국, 클라이언트 입장에서 직관적이고 이해하기 쉽도록 설계 원칙을 지키는 멋진 개발자가 되기 위한 시작이라고 생각합니당.

따라서 클라이언트가 좋아할만한 API Path는 단수형 복수형의 구분 버전 관리 자원의 상태를 나타낼 때는 쿼리 파라미터 사용하기 직관적인 경로 자원 기반 설계 등이 있지 않을까 생각됩니다.