RESTful API란?

💡 RESTful API

💬 REST(Representational State Transfer)란?

• REST란 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미합니다.
• 즉, HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, PATCH, DELETE 등)를 통해 해당 자원에 대한 CRUD(Create, Read, Update, Delete) Operation을 적용하는 것을 의미합니다.

 

💬 API(Application Programming Interface)란?

• API는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의합니다.
• 즉, 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있으며, 서버와 데이터베이스에 대한 출입구 역할을 하고, 애플리케이션과 기기가 원활하게 통신할 수 있도록 도와주며, 모든 접속을 표준화합니다.

 

💬 RESTful API란?

• RESTful API란 말 그대로 REST 설계 규칙을 따르는 API를 의미합니다.
• 다만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다.
• 즉, REST 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다고 말할 수 있습니다.

---

💡 REST 설계 규칙

다음은 REST 아키텍처 스타일의 몇 가지 원칙입니다.

• Uniform Interface(균일한 인터페이스)
  • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행해야 한다.
• Stateless(무상태)
  • 작업을 위한 상태 정보를 따로 저장하고 관리하지 않는다.
  • 즉, 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다.
  • 이러한 이유로 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
• Cacheable(캐시 처리 가능)
  • HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있다. 따라서 HTTP가 가진 캐싱 기능 적용이 가능하다.
  • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용해 구현할 수 있다.
• Self-descriptiveness(자가 설명)
  • REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있어야 한다.
• Client - Server(클라이언트 - 서버 구조)
  • REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로, 각각의 역할을 확실하게 구분해야 한다.
  • 이를 통해, 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어든다.
• Layered System(계층형 시스템)
  
  • REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조 상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 해야 한다.

---

💡 RESTful API를 사용하면 어떤 이점이 있나요?

확장성

REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있습니다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거합니다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거합니다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원합니다.

 

유연성

RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원합니다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리합니다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않습니다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킵니다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있습니다.

 

독립성

REST API는 사용되는 기술과 독립적입니다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있습니다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있습니다.

---

💡 RESTful API는 어떻게 작동하나요?

RESTful API의 기본 기능은 인터넷 브라우징과 동일합니다. 클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속합니다. API 개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명합니다. 다음은 모든 REST API 호출에 대한 일반 단계입니다.

1. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정하여 요청을 전송합니다.
2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인합니다.
3. 서버가 요청을 수신하고 이를 내부적으로 처리합니다.
4. 서버가 클라이언트에 응답을 반환합니다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보와 클라이언트가 요청한 모든 정보가 포함됩니다.

REST API 요청 및 응답 세부 정보는 API 개발자가 API를 설계하는 방식에 따라 약간씩 다를 수 있습니다.

---

💡 RESTful API 클라이언트 요청에는 무엇이 포함되어 있나요?

RESTful API에는 다음과 같은 주요 구성요소를 포함하는 요청이 필요합니다.

 

고유 리소스 식별자

• 서버는 고유한 리소스 식별자로 각 리소스를 식별합니다.
• REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행합니다.
• URL은 리소스에 대한 경로를 지정합니다. 웹페이지를 방문하기 위해 브라우저에 입력하는 웹 사이트 주소와 유사합니다.
• URL은 요청 엔드포인트라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정합니다.

 

메서드

개발자는 종종 Hypertext Transfer Protocol(HTTP)을 사용하여 RESTful API를 구현합니다. HTTP 메서드는 리소스에 수행해야 하는 작업을 서버에 알려주는 역할을 수행합니다. 다음은 4가지의 일반적인 HTTP 메서드입니다.

• GET: 리소스 조회 시 사용
• POST: 리소스 추가/변경 시 사용
• PUT: 리소스 수정 시 사용
• DELETE: 리소스 삭제 시 사용

 

HTTP 헤더

요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터입니다. 예를 들어, 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공합니다.

• 데이터: REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있습니다.
• 파라미터: RESTful API 요청에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있습니다. 다음은 몇 가지 파라미터 유형입니다.
  
  • URL 세부정보를 지정하는 경로 파라미터
  • 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터
  • 클라이언트를 빠르게 인증하는 쿠키 파라미터

---

💡 RESTful API 서버 응답에는 무엇이 포함되어 있나요?

RESTful API는 REST 원칙에 따라 서버 응답에 다음과 같은 주요 구성 요소를 포함해야 합니다.

상태 표시줄

상태 표시줄에는 요청 성공 또는 실패를 알리는 3자리 상태 코드가 있습니다. 예를 들어, 2XX 코드는 성공을 나타내고 4XX 및 5XX 코드는 오류를 나타냅니다. 3XX 코드는 URL 리디렉션을 나타냅니다. 다음은 몇 가지 일반적인 상태 코드입니다.

• 200: 일반 성공 응답
• 201: POST 메서드 성공 응답
• 400: 서버가 처리할 수 없는 잘못된 요청
• 404: 리소스를 찾을 수 없음

 

메시지 본문

응답 본문에는 리소스 표현이 포함됩니다. 서버는 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택합니다. 클라이언트는 데이터 작성 방식을 일반 텍스트로 정의하는 XML 또는 JSON 형식으로 정보를 요청할 수 있습니다. 예를 들어, 클라이언트가 John이라는 사람의 이름과 나이를 요청하면 서버는 다음과 같이 JSON 표현을 반환합니다.

• '{"name":"John", "age":30}'

 

헤더

응답에는 응답에 대한 헤더 또는 메타데이터도 포함됩니다. 이는 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함합니다.

---

💡 REST API URI 설계 원칙

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

Bad Example: /baegwon/Running
Good Example: /baegwon/run

 

2. 마지막에 슬래시(/)를 포함하지 않는다.

Bad Example: /baegwon/test/
Good Example: /baegwon/test

 

3. 언더바(_) 대신 하이픈(-)을 사용한다.

Bad Example: baegwon/test_blog
Good Example: baegwon/test-blog

 

4. 파일 확장자는 포함하지 않는다.

Bad Example: baegwon/photo.jpg
Good Example: baegwon/photo

 

5. 행위를 포함하지 않는다.(리소스에 대한 행위는 HTTP Method로 표현한다.)

Bad Example: baegwon/delete-post/1
Good Example: baegwon/post/1

---

📌 Resources

• https://aws.amazon.com/ko/what-is/restful-api/
• https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80
• https://kmkunk.tistory.com/139