REST API란?
REST
REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미한다.
- HTTP URI(Uniform Resource Identifier)을 통해 자원을 명시하고
- HTTP Method(POST, GET, PUT, DELETE)를 통해
- 해당 자원에 대한 CRUD Operation을 적용한다.
CRUD Operation
- Create: 생성(POST)
- Read: 조회(GET)
- Update: 수정(PUT)
- Delete: 삭제(DELETE)
멱등성
멱등성(idempotent)이란 여러번 수행해도 결과가 같음을 의미한다. 즉, 호출로 인하여 데이터가 변형이 되지 않는다는 것을 의미한다. HTTP Method 중에 POST를 제외하고 모두 멱등성이 보장되어야 한다.
GET방식이 POST방식보다 속도가 빠르다?
GET 방식은 캐싱을 하기 때문에 여러번 요청시 저장된 데이터를 활용하므로 조금 더 빠를 수 있다.
REST 구성요소
- 자원(Resource): HTTP URL
- 자원에 대한 행위(Verb): HTTP Method
- 자원에 대한 행위의 내용(Representations): HTTP Message Pay Load
REST 특징
- Server-Client(서버-클라이언트 구조)
- Stateless(무상태)
- Cacheable(캐시 처리 가능)
- Layered System(계층화)
- Uniform Interface(인터페이스 일관성)
- Code-On-Demand(optional) - Server로부터 스크립트를 받아서 Client에서 실행한다.(선택사항)
REST 장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
REST 단점
- 표준이 자체가 존재하지 않아 정의가 필요하다.
- 사용할 수 있는 메서드가 4가지밖에 없다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 부분이 존재한다.
- PUT, DELETE를 사용할 수 없다.
- pushState를 지원하지 않는다.
REST API
REST API는 REST의 원리를 따르는 API를 의미한다.
API(Application Programming Interface)
응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스이다. 즉, 프로그램과 소통하게 해주는 매개체. 프로그램과 또 다른 프로그램을 연결해주는 다리 역할을 한다고 생각하면 된다.
REST API 디자인 가이드
- 소문자를 사용한다
- RFC3986은 체계 및 호스트 구성요소를 제외하고 URI를 대소문자를 구분하여 정의한다.
- 스네이크케이스(snake_case)대신 케밥케이스(kebab-case)를 사용한다.
- 스네이크케이스는 보기 어렵거나 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
- Path Variable에는 카멜케이스(camelCase)를 사용한다.
- [GET] /users/{userId}
- JSON property에는 카멜케이스(camelCase)를 사용한다.
1 2 3 4
{ userId: '1', userName: 'Youngjae' }
- URI의 마지막에는 슬래시(/)를 포함하지 않는다.
- 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않습니다.
- 계층관계를 나타낼 때는 슬래시 구분자를 사용해야한다.
- 슬래시 문자는 URI의 경로 부분에서 자원 간의 계층적 관계를 나타내기 위해 사용한다.
- 행위(Verb)는 포함하지 않으며, 행위(Verb)는 URL대신 Method를 사용하여 전달한다.
- 파일 확장자는 URI에 포함시키지 않는다.
- Content-Type 이라는 헤더를 통해 전달되는대로 미디어 타입을 사용하여 body의 콘텐츠를 처리하는 방법을 결정한다.
- HTTP에서 제공하는 형식 선택 메커니즘인 Aceept 요청 헤더를 활용하도록 권장해야 한다.
- 전달하고자 하는 자원의 명사를 사용하되, 컨트롤 자원을 의미하는 경우 예외적으로 동사를 허용한다.
- Collection에는 단수가 아닌 복수를 사용한다.
- API 버전을 위해서 서수를 사용한다.
- https://example.com/
v1/…
- https://example.com/
- list 리소스의 경우 갯수도 함께 응답한다.
- list 응답의 경우 파라미터로 limit과 offset 정보를 받는다.
- 상태값을 응답한다.(상태코드 참고)
- Informational 1XX: 정보를 제공하는 응답
- Successful 2XX : 성공적인 응답
- 200 OK: 요청이 성공적으로 수행
- Redirection 3XX
- 메시지 클라이언트의 요청을 완료하기 위해서 추가적인 행동이 필요한 경우
- Client Error 4XX
- 클라이언트가 서버에게 잘못된 요청을 하는 경우
- 401 Unauthorized: 인증이 필요한 페이지를 요청한 경우
- 403 Forbiden: 허용되지 않은 메서드가 있을 때
- 406 Not Acceptable: 허용 불가능
- Server Error 5XX
- 서버에서 오류가 발생하여 정상적으로 요청을 처리할 수 없는 경우
- 500 Internal Server Error: 웹 서버가 처리할 수 없음
- 503 Service Unavailable: 서비스 제공불가, 서버 과부하, 서버 폭주
RESTful API
RESTful은 REST의 원리를 따르는 시스템을 의미한다.
하지만 REST를 사용했다 하더라도 모두가 RESTful 한 것은 아니다.
REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다 말할 수 있으며, 모든 CRUD 기능을 POST로 처리하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만
RESTful 하지 못한 시스템이라고 할 수 있습니다.
RESTful 한 API를 구현하는 근본적인 목적이 성능 향상에 있는 것이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.
Leave a comment