API에 대해서 어렴풋이 알고 있었지만 정확히 어떤 역할을 하는지에 대해서 생각해본 적이 없었다.
이번에 장고에서 REST API 서비스를 만들며 REST와 API에 대한 개념인지 필요성을 느꼈고 정리해보았다.
결과부터 말하자면
REST API는 HTTP요청을 보낼때 어떤 URI에 어떤 메소드를 사용하지 개발자들 사이에서 지켜지는 약속이다.
REST API는 특별한 프로그램이 아니라 하나의 형식이기 때문에 범용적으로 사용가능하다.
API란?
API 정의
- 쉽게 말해 API는 프로그램들의 상호작용을 도와주는 매개체이다. 예를 들어 우리가 식당에 가면 점원은 손님을 안내하고 주문을 받으며 손님이 원하는 메뉴를 주방에 알려준 뒤 메뉴가 나오면 손님에게 전달한다. 여기서 손님은 프로그램, 메뉴는 프로그램이 수행하는 명령 목록, 주문은 명령 마지막으로 주방은 응용프로그램이라고 생각하면 된다.
API 구체적 개념
- API는 서버와 데이터베이스에 대한 출입구 역할을 한다.
데이터베이스에는 소중한 정보들이 저장한다. 모든 사람들이 이 데이터베이스에 쉽게 접근할 수 없게 하기 위해서 API는 여러분이 가진 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근성을 부여해줍니다. - API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
여기서 애플리케이션이란 우리가 흔히 알고 있는 스마트폰 어플이나 프로그램을 말하며 API는 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 합니다. - API는 모든 접속을 표준화한다.
API는 모든 접속을 표준화하기 때문에 기계/ 운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있습니다. 쉽게 말해, API는 범용 플러그처럼 작동한다고 볼 수 있습니다.
출처:
REST란?
REST 정의
- “Representational State Transfer”의 약자, 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다.
- 자원(resource)의 표현(representation)에 의한 상태 전달
- A. 자원(resource)의 표현(representation)
자원 : 해당 소프트웨어가 관리하는 모든 것 예) 문서, 그림, 데이터, 해당 소프트웨어 자체 등
자원의 표현 : 그 자원을 표현하기 위한 이름 예) DB의 학생 정보가 자원일 때, ‘students’를 자원의 표현으로 정한다. - B. 상태(정보) 전달
데이터가 요청되는 시점에서 자원의 상태(정보)를 전달한다.
JSON 혹은 XML를 통해 데이터를 주고받는 것이 일반적이다. - REST는 네트워크상에서 Client와 Server 사이의 통신 방식 중 하나이다.
- A. 자원(resource)의 표현(representation)
REST 구체적 개념
- HTTP URL(Uniform Resource Identifier)을 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
- 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미한다.
- 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URL를 부여한다.
- CRUD Operation
- Create : 생성(POST)
- Read : 조회(GET)
- UPdate : 수정(PUT)
- Delete : 삭제(DELETE)
- HEAD : header 정보 조회(HEAD)
REST API란
API
- API는 하나의 애플리케이션이나 서비스가 다른 애플리케이션이나 서비스 내의 리소스에 액세스 할 수 있도록 해주는 메커니즘입니다. 액세스를 수행하는 애플리케이션이나 서비스를 클라이언트라고 하며, 리소스가 포함된 애플리케이션이나 서비스를 서버라고 합니다.
REST API
- REST 기반으로 서비스 API를 구현하는 것
REST API는 거의 모든 프로그래밍 언어를 사용하여 개발이 가능하며, 다양한 데이터 포맷을 지원할 수 있습니다. 유일한 요구사항은 이들이 아키텍처 제한사항으로도 알려진 다음의 6가지 REST 디자인 원칙에 맞아야 한다는 것입니다.
- 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
- 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
- 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
- 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스
- 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 합니다.
- 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 합니다(이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문).
- 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
- 하이퍼미디어: 클라이언트가 리소스에 액세스 한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.
- 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.
- 코드 온디맨드(선택 사항): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능.
REST API의 규칙
1. 슬래시 구분자(/ )는 계층 관계를 나타내는 데 사용한다.
2. URL 마지막 문자로 슬래시(/ )를 포함하지 않는다.
- URL에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며,
URL가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URL도 달라져야 한다. - REST API는 분명한 URL를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URL 경로의 마지막에는 슬래시(/ )를 사용하지 않는다.
3. 하이픈(- )은 URL 가독성을 높이는 데 사용한다.
- 불가피하게 긴 URL 경로를 사용하게 된다면 하이픈을 사용해 가독성을 높여준다.
4. 밑줄(_ )은 URL에 사용하지 않는다.
- 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
5. URL 경로에는 소문자가 적합하다.
- URL 경로에 대문자 사용은 피하도록 한다.
- PFC 3986(URL 문법 형식)은 URL 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.
6. 파일 확장자는 URL에 포함하지 않는다.
- REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URL안에 포함시키지 않는다.
- Accep header를 사용한다.
- Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
- Ex) GET /members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
7. 리소스 간에는 연관 관계가 있는 경우
- /리소스명/리소스 ID/관계가 있는 다른 리소스명
- Ex) GET : /users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때)
출처: https://hanamon.kr/rest-api/
REST API설계 예시
- 참고: HTTP 응답 상태 코드
- what is different between URL & URI
- URI - URI는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미한다. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스다.
- URL - URL은 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약이다. URI의 서브셋이다.
댓글