Restful API 에 대하여(개념/정리)

오늘은 주니어 기술면접의 단골 질문인 Restful API에 대해 설명해보겠다.

 

 

RESTful API란?

 

REST API는 Representational State Transfer의 약자로, 웹 기반 통신에서 자원을 정의하고 자원에 대한 주소를 사용하여 정보를 주고받는 방법을 의미한다. 이는 클라이언트와 서버 간의 통신을 위한 아키텍처 스타일 중 하나로, 웹의 기본적인 기술과 프로토콜을 사용한다. 주로 HTTP 프로토콜을 이용하여 데이터를 송수신하며, 자원의 상태를 CRUD(생성, 조회, 수정, 삭제) 작업을 통해 관리한다.

 

RESTful API 특징

 

REST API는 다음과 같은 특징을 갖는다:

• 스테이트리스(Stateless) 통신: 서버가 클라이언트의 상태를 저장하지 않는다. 즉, 각각의 요청이 독립적이며, 이전 요청의 정보를 기반으로 하지 않는다.
• 캐시 가능(Cacheable): HTTP의 기본적인 캐싱 메커니즘을 사용할 수 있어, 네트워크 대역폭 사용을 줄이고 성능을 향상시킬 수 있다.
• 계층화(Hierarchical): 클라이언트는 보통 중간 서버를 통해 서버에 접근한다. 이로 인해 서버의 확장성과 보안이 향상될 수 있다.
• 통합 인터페이스(Uniform Interface): 애플리케이션과 서버 간의 통신을 위한 표준 방식을 제공한다. 이로 인해 다양한 클라이언트에서 서버의 자원에 접근할 수 있다.

RESTful API를 구현함으로써, 웹 서비스는 다양한 플랫폼과 언어로 작성된 클라이언트 애플리케이션에 서비스를 제공할 수 있다. 이는 웹 애플리케이션, 모바일 애플리케이션, 다른 서버 애플리케이션 등 다양한 클라이언트에서 사용될 수 있는 효율적이고 확장 가능한 방법을 제공한다.

 

중요 개념

1. 리소스 (Resource):
   • REST API의 수행 대상이 되는 리소스는 **URI(Uniform Resource Identifier)**로 정의된다.
   • 리소스는 처리되는 대상을 의미하며, JSON, XML 문서, 이미지, 비디오 등이 될 수 있다.
   • URI는 특정 자원의 위치를 나타내는 주소로, HTTP나 FTP 프로토콜과 함께 사용된다.
2. 메소드 (Method):
   • REST API에서 리소스에 대한 행위는 HTTP Method로 정의된다.
   • 주요 HTTP 메소드로는 POST, GET, PUT, PATCH, DELETE 등이 있다.
   • 이들 메소드는 각각 CRUD(Create, Read, Update, Delete) 연산과 매핑된다.
3. 표현 (Representation):
   • HTTP 메소드와 URI로는 원하는 내용을 모두 표현할 수 없다.
   • 예를 들어 새로운 유저를 생성하는 REST API는 JSON이나 XML과 같은 표현 언어를 이용하여 정보를 전달한다.
   • 페이로드(Payload)를 통해 리소스를 표현하며, Content-Type 헤더를 통해 페이로드를 해석한다.

참고로 여기서 설명한 메소드에는 4가지 외에도 굉장히 많은 메서드 들이 존재한다.

그러나 주로 다 쓰지 않고 API의 상황에 따라 4가지 이상을 쓸 수도 있고, 반대로 GET과 POST로만 모든 것을 제한할 수도 있다. 이는 설계에 따라 달라진다.

 

참고사항

URI와 URL의 차이

 

URL(Uniform Resource Locator)은 웹 브라우저와 같은 클라이언트가 서버에게 특정 자원을 요청할 때 사용되는 문자열로, 인터넷에서 특정 리소스의 위치를 지정한다. URL은 일반적으로 프로토콜, 호스트 주소, 자원의 경로 등의 요소로 이루어져 있다.

 

예를 들어, "https://www.example.com/index.html"은 다음과 같이 구성된다:

• 프로토콜: "https://"
• 호스트 주소: "www.example.com"
• 자원의 경로: "/index.html"

이 URL은 HTTPS 프로토콜을 사용하여 "www.example.com" 서버에 있는 "index.html"이라는 파일을 요청하는 것을 의미한다.

 

URI(Uniform Resource Identifier)는 인터넷 상의 리소스를 식별하는 일반적인 용어이다. URL은 URI의 하위 개념으로, 리소스의 위치를 지정하는 특별한 형태의 URI이다. 즉, URL은 URI의 한 형태로 볼 수 있다.

URL과 URI의 주요 차이점은 다음과 같다:

• URL은 인터넷 상의 리소스의 위치를 지정하는 문자열로, 리소스를 어디서 찾을 수 있는지를 나타낸다.
• URI는 리소스를 식별하는 일반적인 용어로, URL뿐만 아니라 URN(Uniform Resource Name)과 같은 다른 형태의 식별자를 포함한다.

즉 간단히 말해 URI는 식별자 이고 URL은 식별자+위치 이다.

 

Restful API의 응답 코드

 

응답 코드설명

 

Restful API를 사용하여 만든 API는 오류가 생겼을 때, 각 상태 코드로 클라이언트에게 요청의 결과를 표현해 준다. 이는 완벽히 정해진 것이 아니라 통상적으로 이렇게 나누어 쓰이며 개발자가 커스텀하게 만들어서 내려줄 수도 있다. 그러나 일반적인 규칙으론 아래와 같이 정보를 나타내준다.

 

1xx - 정보

1. 100 Continue (계속): 클라이언트가 요청을 계속해도 좋음을 나타낸다. 주로 요청의 일부를 보낸 후 서버가 계속할지 여부를 결정할 때 사용된다..

2xx - 성공

1. 200 OK: 요청이 성공적으로 처리되었고, 서버가 요청한 자원을 정상적으로 반환했음을 나타낸다.
2. 201 Created: 요청이 성공적으로 처리되었고, 새로운 자원이 성공적으로 생성되었음을 나타낸다.

3xx - 리다이렉션

1. 300 Multiple Choices (다중 선택): 클라이언트의 요청에 대해 여러 가지 선택지가 있음을 나타낸다. 클라이언트는 선택된 자원에 대한 추가적인 요청을 해야 한다.
2. 301 Moved Permanently (영구적으로 이동함): 요청한 자원이 새로운 위치로 영구적으로 이동되었음을 나타낸다.

4xx - 클라이언트 오류

1. 400 Bad Request: 클라이언트의 요청이 서버에 의해 이해되지 않거나 잘못된 구문을 포함하고 있어서 서버가 요청을 처리할 수 없음을 나타낸다.
2. 401 Unauthorized: 클라이언트가 요청을 보낼 권한이 없거나 인증되지 않았음을 나타낸다.

5xx - 서버 오류

1. 500 Internal Server Error: 서버에서 요청을 처리하는 동안 예상치 못한 오류가 발생했음을 나타낸다.
2. 503 Service Unavailable: 서버가 현재 요청을 처리할 수 없음을 나타낸다. 주로 서버가 과부하 상태에 있거나 일시적으로 점검 중일 때 반환된다.

 

아래는 자주 나오는 응답 코드를 보여준다.

200 OK	요청이 성공적으로 처리되었고, 응답으로 요청한 자원이 반환됨
201 Created	요청이 성공적으로 처리되었고, 새로운 자원이 생성되었음
400 Bad Request	클라이언트의 요청이 잘못되었거나 서버가 요청을 이해할 수 없음
401 Unauthorized	클라이언트가 인증되지 않았거나 인증 정보가 유효하지 않음
403 Forbidden	클라이언트가 요청을 수행할 권한이 없음
404 Not Found	요청한 자원이 서버에서 찾을 수 없음
405 Method Not Allowed	요청된 HTTP 메서드가 허용되지 않음
500 Internal Server Error	서버가 요청을 처리하는 동안 예기치 않은 오류가 발생함
503 Service Unavailable	서버가 현재 요청을 처리할 수 없음

 

 

위 와 같은 특성이 있기 때문에  응답 코드를 보고 어디서 문제가 났는지 개발자는 유추가 가능하다.

 

예를 들어 GET 방식으로 https://openapi.naver.com/v1/search/news 의 URL로 호출을 하였을 때,

200이 되돌아 왔다면 성공을 유추할 수 있다.

 

그러나 404가 나왔다면 해당 리소스에 대한 자원을 찾을 수 없다는 것을 유추하고, 내가 URL을 잘 못 입력 했거나 찾으려는 자원이 삭제됨을 가정 할 수 있다.

 

그러나 401이 나왔을 경우 자원은 찾았는데 인증이 안되어 거절 당했다고 유추가 가능하며 클라이언트에서 서버로 보낼 때의 헤더나 토큰을 확인 하는 등 인증 관련 문제로 범위를 좁힐 수 있다.

 

재미있는건 면접에서 401과 403의 접근 방식의 차이를 물어볼 수도 있다는 것이다.

1개의 질문으로 2가지 질문이 가능하다. 

 

첫번째 인증과 권한의 차이를 아는가

두번째 해당 문제점의 해결에 대한 접근을 어떻게 접근할 것인가.

 

이처럼 응답코드는 클라이언트에게 결과에 대한 힌트를 주는 것이다.

이 코드들을 보고 클라이언트는 응답에 대한 분기를 결정하거나 문제점을 해결 할 수 있다.

 

GET과 POST의 차이점

1. 데이터 전송 방식:
   • GET: GET 요청은 URL을 통해 데이터를 전송한다. 요청은 URL의 일부로 데이터가 포함되어 있으며, 브라우저 주소 표시줄에도 나타날 수 있다. 데이터는 URL의 일부로 노출되므로 주로 데이터 전송에 제한이 있고, 보안에 취약하다. 또한, GET 요청은 캐싱될 수 있으므로 데이터가 노출되지 않아야 하는 경우에는 적합하지 않다.
   • POST: POST 요청은 HTTP 요청의 본문(body)에 데이터를 포함하여 전송한다. 이는 데이터가 URL에 노출되지 않으므로 GET보다 보안적으로 강력하다. POST 요청은 보통 데이터 양에 제한이 없으며, 이를 통해 큰 데이터를 전송할 수 있다.
2. 데이터 길이 제한:
   • GET: 대부분의 브라우저 및 서버에서 GET 요청의 길이에 제한을 둔다. 이는 URL의 길이에 제한이 있는 경우가 많아, GET 요청으로 보낼 수 있는 데이터의 양이 제한될 수 있다.
   • POST: POST 요청은 일반적으로 데이터 길이에 대한 제한이 없다. 따라서 POST 요청을 통해 더 많은 양의 데이터를 전송할 수 있다.
3. 캐싱:
   • GET: GET 요청은 캐싱될 수 있다. 이는 동일한 GET 요청이 다시 실행될 때 이전에 받은 응답이 사용될 수 있다는 것을 의미한다.
   • POST: POST 요청은 기본적으로 캐싱되지 않다. 매번 새로운 요청이 서버로 전송된다.
4. 보안:
   • GET: GET 요청은 URL에 데이터를 노출시키므로 보안에 취약하다. 예를 들어, 로그인 정보와 같은 민감한 데이터를 GET 요청으로 전송하는 것은 안전하지 않다.
   • POST: POST 요청은 데이터가 HTTP 요청의 본문에 포함되므로 GET보다 보안적으로 더 안전하다. 따라서 민감한 데이터를 전송할 때 주로 사용된다.

 

POST와 PUT의 차이

 

1. 목적:
   • POST: POST 요청은 새로운 엔터티를 생성하거나 서버의 리소스에 데이터를 추가하기 위해 사용된다. 일반적으로 서버가 새로운 리소스의 URI를 결정하고 클라이언트에게 반환한다.
   • PUT: PUT 요청은 서버의 특정 URI에 리소스를 저장하거나 업데이트하기 위해 사용된다. 클라이언트가 요청 본문에 리소스의 전체 표현을 제공하고, 이를 서버에 업로드하거나 저장한다. 이미 존재하는 리소스의 전체를 대체한다.
2. 사용하는 리소스의 상태:
   • POST: POST 요청은 보통 서버가 관리하는 컬렉션(collection)에 새로운 엔터티를 추가하기 위해 사용된다. 예를 들어, 블로그 게시물을 추가하거나 새로운 주문을 생성하는 등의 작업에 사용된다.
   • PUT: PUT 요청은 주로 특정 리소스의 상태를 변경하거나 업데이트하는 데 사용된다. 이미 존재하는 리소스를 업데이트하거나 서버에 새로운 리소스를 저장하기 위해 사용된다.
3. 멱등성(Idempotence):
   • POST: 일반적으로 POST 요청은 멱등하지 않다. 동일한 POST 요청을 여러 번 실행하면 각각 다른 리소스 또는 상태를 만들 수 있다.
   • PUT: PUT 요청은 멱등합니다. 동일한 PUT 요청을 여러 번 실행하더라도 최종 결과는 동일하다. PUT 요청은 동일한 데이터를 반복적으로 서버에 저장하더라도 항상 같은 결과를 제공한다.

멱등성이란?

멱등성(Idempotence)은 동일한 작업을 여러 번 수행하더라도 결과가 동일하게 유지되는 특성을 의미한다. 즉, 멱등한 작업은 처음 실행했을 때와 후속 실행에서 결과가 변경되지 않다.

 

예를 들어, 어떤 함수나 연산이 멱등하다면, 이를 여러 번 호출해도 최종 결과는 변하지 않는다.

 

HTTP 메서드멱등성캐시 가능 여부설명

 

GET	멱등	일반적으로 캐시됨	- 동일한 GET 요청을 여러 번 실행해도 결과가 변하지 않다.
PUT	멱등	일반적으로 캐시되지 않음	- 동일한 데이터를 여러 번 업로드하더라도 최종 결과는 동일.
POST	비멱등	일반적으로 캐시되지 않음	- 새로운 데이터를 서버에 추가하므로 여러 번 실행하면 각각 다른 상태를 만들 수 있다.
DELETE	멱등	일반적으로 캐시되지 않음	- 동일한 삭제 요청을 여러 번 보내더라도 리소스는 항상 삭제된다.