REST API
REST란?
REST(Representational State Transfer)의 약자로 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다.
API란?
API(애플리케이션 프로그래밍 인터페이스, Application Programming Interface)는 서로 다른 소프트웨어나 시스템 간의 상호작용을 가능하게 하는 규칙과 도구의 모음입니다.
API는 프로그램이 다른 프로그램의 기능을 호출하거나 데이터를 주고받을 수 있게 해 주며, 개발자들이 복잡한 내부 구현을 알 필요 없이 특정 기능을 사용할 수 있도록 돕습니다.
카페에서 커피를 주문하는 것을 예로 들어보겠습니다.
고객(클라이언트)는 종업원(API)를 통해서 아메리카노(리소스)를 주문합니다.
고객은 서비스를 요청하는 주체인 클라이언트입니다.
종업원은 클라이언트에게 요청을 받아 리소스를 전달하는 API입니다.
이렇게 종업원이 만든 아메리카노는 클라이언트 요청의 응답인 리소스입니다.
이 과정에서 고객은 커피가 어떻게 만들어지는지 몰라도 주문을 한다면 아메리카노를 받을 수 있습니다.
REST API란?
REST API란 REST 아키텍처 스타일의 설계 원칙을 준수하는 API입니다.
카페에서 커피를 주문하는 과정에서 종업원이 키오스크로 바뀌었다고 가정해보겠습니다.
키오스크는 메뉴 선택, 결제 방법 입력, 결제라는 3가지 단계를 통해서 아메리카노 주문이 가능합니다.
키오스크의 작동 방식(REST)을 준수하며 커피를 주문하는 것이 REST API 입니다.
REST 구성요소
자원(Resource): HTTP URI
URI는 웹 상에서 자원을 식별하는 고유한 주소입니다.
REST에서 URI는 자원을 명확하게 식별하는데 중요한 역할을 하며,
자원의 상태나 동작을 나타내는 것이 아니라 자원 자체를 명확하게 나타내야 합니다.
URI vs URL
URI와 URL의 차이점
URI(Uniform Resource Identifier)는 인터넷 상의 리소스 자원 자체를 식별하는 고유한 문자열 시퀀스 입니다.
URI는 그 자체로 이름이 될 수 있습니다.
URL(Uniform Resource Locator)는 인터넷 상에서 통한 자원(리소스)의 위치를 나타내기 위한 규약합니다. 즉 자원 식별자와 위치를 동시에 보여주는 것 입니다.
URL은 프로토콜과 결합한 형태인데 프로토콜이란 리소스에 접근하는 방법을 지정하는 방식입니다. 일반적으로 https, http, ftp등이 해당됩니다.
URI은 URL를 포함하는 구조입니다.
ex)
https://www.naver.com → URL
www.naver.com, https://www.naver.com → URI
URI 설계
리소스 중심 설계
URI는 동사보다 명사를 그리고 주로 복수형을 많이 사용합니다.
Bad : /Running
Good: /run, /users, /products, /orders
URI 마지막에 슬래시를 포함하지 않습니다.
Bad: naver.com/blog/
Good: naver.com/blog
언더바 대신 하이픈 사용
Bad: naver.com/blog_post
Good: naver.com/blog-post
파일의 확장자를 포함하지 않습니다.
Bad: naver.com/blog/photo.png
Good: naver.com/blog/photo
행위를 포함하지 않습니다.
Bad: naver.com/delete-blog/26
Good: naver.com/blog/26
행위(Verb): HTTP Method
자원의 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현합니다.
그리고 행위를 알맞게 사용해야됩니다.
멱등성(Idempotent)
서버에 요청을 한 번 보낸 결과와 여러번 보낸 결과가 서버에 미치는 영향이 동일하다는 것을 의미합니다.
GET
GET 메서드는 리소스를 조회하는 데 사용됩니다. GET 요청은 안전하고 멱등성을 가집니다.
- 안전함 (Safe): GET 요청은 서버의 상태를 변경하지 않습니다. 즉, GET 요청은 데이터를 조회하는 데만 사용되며, 서버에 있는 데이터를 수정하지 않습니다.
- 멱등성 (Idempotent): 동일한 GET 요청을 여러 번 반복해도 결과는 항상 동일합니다. 이는 서버의 상태를 변경하지 않기 때문입니다.
POST
POST는 새로운 리소스 생성하는데 사용됩니다.
- 비멱등성 (Non-idempotent): 동일한 POST 요청을 여러 번 반복하면 서버에 여러 개의 리소스가 생성될 수 있습니다. 예를 들어, 동일한 POST 요청을 두 번 보내면 두 개의 새로운 리소스가 생성될 수 있습니다.
- 데이터 변경: POST 요청은 서버의 상태를 변경합니다. 따라서 GET 요청을 통해 조회되는 데이터도 변경될 수 있습니다.
PUT
PUT은 리소스 전체 업데이트(덮어쓰기)를 합니다.
- 멱등성 (Idempotent): 동일한 PUT 요청을 여러 번 반복해도 결과는 동일합니다.
- 데이터 변경: PUT 요청은 서버의 상태를 변경할 수 있으며, 리소스를 전체적으로 갱신합니다.
PATCH
PATCH는 리소스 부분 업데이트를 합니다. PUT과 다른점은 전체가 아닌 부분 업데이트 입니다.
- 멱등성 (Idempotent): 동일한 PATCH 요청을 여러 번 반복해도 결과는 동일합니다.
- 데이터 변경: PATCH 요청은 서버의 상태를 변경할 수 있으며, 리소스를 부분적으로 갱신합니다.
DELETE
DELETE는 리소스를 제거합니다.
- 멱등성 (Idempotent): 동일한 DELETE 요청을 여러 번 반복해도 결과는 동일합니다. DELETE가 왜 여러번 반복해도 결과가 동일한지에 대한 의문이 있을텐데 이유는, 첫 번째 요청 이후 리소스가 지워지고 이후에 계속 반복 요청해도 동일한 요청에 대한 데이터는 이미 지워졌기 때문에 결과가 동일합니다. 다시 말해, DELETE 요청을 여러 번 보내더라도 처음 요청 이후 서버의 상태는 변하지 않습니다.
- 데이터 변경: PATCH 요청은 서버의 상태를 변경할 수 있으며, 리소스를 부분적으로 갱신합니다. 이로 인해 GET 요청을 통해 조회되는 데이터도 변경될 수 있습니다.
OPTION
클라이언트가 서버의 통신 가능한 옵션을 조회하기 위해 사용됩니다. 주로 CORS(Cross-Origin Resource Sharing) 설정을 확인하기 위해 사용되지만, 서버의 기능을 확인하는 데에도 유용합니다.
표현(Representations): HTTP Message Payload
이 정보는 JSON, HTML, XLT, Python, PHP, XML 또는 일반 텍스트를 포함한 다양한 형식으로 자원의 상태를 표현하는데 사용됩니다.
JSON은 사람과 기계 모두 읽을 수 있고 프로그래밍 언어에 구애받지 않기 때문에 널리 사용됩니다.
REST 설계 원칙
균일한 인터페이스
동일한 리소스에 대한 모든 API 요청은 요청의 출처에 관계없이 동일한 응답(Response)를 제공해야 됩니다.
REST API는 중복된 URI가 존재하면 안되며, 데이터가 하나의 URI로 접근할 수 있어야합니다.
리소스가 너무 커서는 안 되며 클라이언트가 필요로 할 수 있는 모든 정보를 포함해야 합니다. 즉, 자원을 적절하게 나누고 필터링하여 클라이언트가 해당 자원에 대해서 필요한 리소스만 요청할 수 있도록 설계해야 됩니다.
클라이언트-서버 분리
REST API 설계에서 클라이언트 및 서버 애플리케이션은 서로 완전히 독립적이어야 합니다.
클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이고, 서버 애플리케이션과 다른 방법으로 통신할 수 없습니다.
마찬가지로 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 클라이언트 애플리케이션을 전달하는 것 외에는 클라이언트 애플리케이션을 수정해서는 안 됩니다.
무상태
REST API는 무상태성이기 때문에 각 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다.
즉, REST API에는 서버 측 세션이 필요하지 않다는 의미입니다.
서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.
캐시 가능성
가능한 경우 클라이언트나 서버 측에서 리소스를 캐시할 수 있어야 합니다.
서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다.
목표는 클라이언트 측의 성능을 향상시키는 동시에 서버 측의 확장성을 높이는 것입니다.
캐싱의 핵심 목적은 클라이언트가 같은 요청을 반복적으로 보낼 때, 매번 서버에 요청하지 않고 캐싱된 데이터를 재사용하여 응답 시간을 줄이고 네트워크 트래픽을 줄이는 것입니다.
계층화된 시스템 아키텍처
REST API에서는 호출과 응답이 서로 다른 계층을 거칩니다.
일반적으로 클라이언트와 서버 애플리케이션이 서로 직접 연결된다고 가정하지 않습니다.
통신 루프에는 다양한 중개자가 있을 수 있고, REST API는 클라이언트나 서버가 최종 애플리케이션과 통신하는지 중개자와 통신하는지 알 수 없도록 설계해야 합니다.
코드 온디맨드(선택 사항)
REST API는 일반적으로 정적 리소스를 전송하지만 경우에 따라 응답에 실행 코드(예: Java 애플릿)가 포함될 수도 있습니다. 이러한 경우 코드는 온디맨드 방식으로만 실행되어야 합니다.
이 원칙을 적용하면 서버로부터 실행 코드를 받아서 실행하고, 원래 기능 외에 추가적인 동작을 수행할 수 있게 됩니다. 특히 웹 환경에서 자주 사용됩니다.
RESTful API란?
RESTful이란 REST의 원리를 따르는 시스템을 의미합니다. 하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다.
REST의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다라고 말합니다.
REST를 사용했지만 REST의 위에서 말한 URI 설계 규칙과 HTTP Method를 위반하는 설계는 RESTful 시스템이라고 말할 수 없습니다.
REST의 설계 규칙을 잘 지킨 시스템이 비로소 RESTful API라고 볼 수 있습니다.
예를 들어서 키오스크 주문 시스템이 카페에 존재합니다. 이 주문 시스템은 우리가 말하는 REST API라고 가정을 한다고 하면 키오스크를 통해서 정해진 방식으로 주문을 한다면 RESTful 하다고 볼 수 있습니다.
하지만 카페 주인이 키오스크를 개조해서 카드 결제만 되는 기존 키오스크에 현금 결제와 쿠폰 결제등 다양한 기능을 추가하고 원래 있던 기능을 빼거나 수정한다면 기존 규칙과 설계에 벗어나는 행동임으로 해당 키오스크는 이제 RESTful 하다고 볼 수 없습니다.
마무리
REST와 RESTful이 무엇인지와 REST를 지키기 위해서 어떻게 API를 만들어야 되는지에 대해서 알아보았습니다.
그 과정에서 URI, URL의 차이점, HTTP Method에 멱등성 등 중요한 개념이 중간 중간에 등장하면서 같이 알아보게 되었습니다.
긴 글 읽어주셔서 감사합니다! 질문과 피드백은 언제나 환영입니다 🙇
