REST API

REST API - https://www.ibm.com/topics/rest-apis

REST API는 REST(Representational State Transfer) 아키텍처 스타일의 설계 원칙을 따르는 *API로, 응용 프로그램이나 기기가 서로 연결되어 통신할 수 있는 규칙의 집합입니다. REST API는 상호작용하는 클라이언트와 서버 구성 요소 사이에 관련된 각 리소스를 식별하는 데에 리소스 식별자를 사용합니다.RESTful API라고도 불리며, 컴퓨터 과학자 Roy Fielding이 만들었습니다. REST API를 활용하면 RESTful 웹 서비스와 상호작용할 수 있습니다.

*** API ***

API는 "Application Programming Interface"의 약어로, 프로그램 간 상호작용을 위한 인터페이스를 의미합니다. 즉, 다른 서비스나 소프트웨어와 상호작용하기 위한 방법을 제공하는 도구입니다.

REST design principles ( REST 설계 규칙 )

• Uniform Interface (일관된 인터페이스)

리소스에 대한 모든 API 요청은 어디에서 요청이 왔는지에 관계없이 모두 같은 모습을 유지해야 합니다. REST API는 동일한 데이터 조각이 URI와 연결되도록 보장해야 합니다. 이는 리소스가 너무 크지 않으면서도 클라이언트가 필요로 하는 모든 정보를 포함해야 합니다.

• Client-Server Decoupling (클라이언트-서버 분리)

REST API 디자인에서 클라이언트 및 서버 응용 프로그램은 서로 완전히 독립적이어야 합니다. 클라이언트 응용 프로그램이 알아야 하는 유일한 정보는 요청한 리소스의 *URI이어야 합니다. 또한 서버 응용 프로그램은 HTTP를 통해 요청된 데이터를 전달하는 것 외에는 클라이언트 응용 프로그램을 수정하지 않아야 합니다.

• Stateless (상태 정보 저장 안함)

REST API는 상태 정보를 저장하지 않으며, 각 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다. 즉, REST API는 서버 측 세션을 요구하지 않습니다. 서버 응용 프로그램은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.

• Cacheability (캐시 사용 가능)

가능한 경우, 리소스는 클라이언트 또는 서버 측에서 캐시할 수 있어야 합니다. 또한 서버 응답은 전달된 리소스에 대해 캐시를 허용하는지 여부에 대한 정보를 포함해야 합니다. 이를 통해 클라이언트 측 성능을 향상시키고 서버 측 확장성을 높일 수 있습니다.

• Layered System Architecture (계층화된 시스템 아키텍처)

REST API에서 호출과 응답은 서로 다른 계층을 통해 이루어집니다. 클라이언트와 서버 응용 프로그램이 직접 연결된 것이 아닙니다. 통신 루프에는 여러 가지 중개자가 있을 수 있습니다. REST API는 클라이언트나 서버 모두가 최종 응용 프로그램과 중개자를 구분하지 못하도록 설계되어야 합니다.

• Code on demand (실행 가능한 코드 요청)

REST API는 일반적으로 정적인 자원을 전송하지만, 특정 경우에는 자바 애플릿과 같은 실행 가능한 코드도 응답으로 포함될 수 있습니다. 이러한 경우에는 코드가 필요할 때만 실행되어야 합니다.

REST의 창시자인 Roy Fielding은 Code-On-Demand 제약 조건을 다음과 같이 정의하고 있습니다. REST는 클라이언트 기능을 애플릿이나 스크립트 형태로 다운로드하고 실행함으로써 확장할 수 있습니다. 이를 통해 클라이언트를 단순화하여 미리 구현해야 하는 기능 수를 줄일 수 있습니다.

 

*** URI ****

URI란 Uniform Resource Identifier의 약어로, 인터넷 상의 자원을 식별하기 위한 문자열이다. URI에는 URL과 URN이라는 두 가지 하위 개념이 있다. URL은 Uniform Resource Locator의 약어로, 인터넷 상의 자원의 위치를 나타내는 식별자이다. 즉, URL은 어떤 자원이 어디에 있는지를 나타낸다. 반면, URN은 Uniform Resource Name의 약어로, 자원의 이름을 식별하는 식별자이다. URN은 자원의 위치와 상관없이 자원의 이름만으로 식별할 수 있다. 예를 들어, 책의 ISBN 번호는 URN의 예시이다.

 

How REST APIs work ( REST API의 작동 방식 )

REST API는 HTTP 요청을 통해 리소스 내에서 표준 데이터베이스 기능 CRUD(생성, 조회, 업데이트, 삭제)를 수행합니다. 예를 들어, REST API는 GET 요청을 사용하여 레코드를 검색하고, POST 요청을 사용하여 새 레코드를 만들고, PUT 요청을 사용하여 레코드를 업데이트하고, DELETE 요청을 사용하여 레코드를 삭제합니다. 모든 HTTP 메서드는 API 호출에서 사용될 수 있습니다. 잘 설계된 REST API는 내장 HTTP 기능이 있는 웹 브라우저에서 실행되는 웹 사이트와 유사합니다.

특정 시간대의 리소스 상태 또는 타임스탬프를 리소스 표현이라고 합니다. 이 정보는 JavaScript Object Notation(JSON), HTML, XLT, Python, PHP 또는 일반 텍스트를 포함한 거의 모든 형식으로 클라이언트에 전달될 수 있습니다. JSON은 사람과 기계 모두가 읽기 쉬우며 프로그래밍 언어에 대한 제약이 없어 인기가 있습니다.

요청 헤더와 매개 변수는 REST API 호출에서 중요합니다. 메타데이터, 권한, 통합 자원 식별자(URIs), 캐싱, 쿠키 등과 같은 중요한 식별자 정보를 포함합니다. 요청 헤더와 응답 헤더는 잘 설계된 REST API에서 사용되며, 규약적인 HTTP 상태 코드와 함께 사용됩니다.

앱 개발자는 REST API를 사용하여 서버에서 데이터를 가져오거나 서버에 데이터를 보낼 수 있습니다. 그러나 REST API를 사용할 때는 몇 가지 고려해야 할 점이 있습니다.

첫째, URI는 정보의 자원을 표현해야 합니다. URI는 서버의 자원을 정의하고 자원에 대한 주소를 지정합니다. 따라서 URI를 효율적으로 설계해야 합니다.

둘째, HTTP Method(GET, POST, PUT, DELETE)를 적절하게 사용해야 합니다. GET은 데이터를 가져올 때, POST는 데이터를 생성할 때, PUT은 데이터를 업데이트할 때, DELETE는 데이터를 삭제할 때 사용됩니다. 따라서 HTTP Method를 올바르게 선택하고 사용해야 합니다.

셋째, 보안 문제에 대해 충분한 고민이 필요합니다. REST API를 사용하면서 발생할 수 있는 보안 문제를 예방하고 대비해야 합니다. 예를 들어, 사용자 인증 및 권한 부여, *SSL(HTTPS)을 사용하여 통신 암호화, *CSRF 및 *XSS 방어 등이 있습니다.

넷째, API 문서화를 충분히 해야 합니다. REST API를 사용할 때는 API 문서화가 매우 중요합니다. API 문서화는 개발자들이 API를 이해하고 사용할 수 있도록 도와줍니다. 따라서 API 문서화를 충분히 하여 사용자들이 쉽게 API를 사용할 수 있도록 해야 합니다. 

 

*** SSL, CSRF, XSS ***

SSL은 Secure Socket Layer의 약자로, 웹사이트와 사용자 사이의 데이터 통신을 암호화하여 보안을 강화합니다. SSL 인증서를 통해 웹사이트의 신원을 인증하고, HTTPS 프로토콜을 사용하여 암호화된 통신을 합니다. SSL의 적용을 통해 중간자 공격을 방지하고 데이터의 안전성을 높일 수 있습니다.

 

CSRF는 Cross-Site Request Forgery의 약자로, 사용자가 의도하지 않은 요청을 처리하도록 유도하는 공격입니다. 이 공격을 방지하기 위해 Django와 같은 웹 프레임워크에서는 CSRF 공격을 방지하는 미들웨어를 제공하고 있습니다.

 

XSS는 Cross-Site Scripting의 약자로, 웹 애플리케이션에서 입력값을 검증하지 않아 악의적인 스크립트를 삽입하거나 실행시키는 공격입니다. XSS 공격으로 인해 해커는 사용자의 정보를 탈취하거나 관리자 권한을 탈취할 수 있습니다. 이를 방지하기 위해서는 입력값 검증 및 출력값 인코딩 등의 보안 대책을 적용해야 합니다.