한줄요약:
HTTP 메소드를 사용하여 서버와 클라이언트간 자원을 활용하는 방법을 정의한 것.
REST API : Representational State Transfer Application Programming Interface
HTTP 메소드를 이용하여 URI에 대한 행위를 정의하는 것.
HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD 를 적용하는 것
자원(ROA: Resource Oriented Architecture)기반구조
RESTful : REST API의 설계 의도를 정확하게 지켜주는 API를 통칭하는 말.
RESful 한 API는 구성요소들의 역할이 명확하게 분리되어있어야 한다.
URI는 자원을 정확하고 인식하기 편하게 표현하는데 집중
자원에 대한 행위는 Uniform하게 HTTP 메소드를 통해 정의한다.
나머지 payload는 json이나 xml 같은 언어를 이용하여 별도로 정의한다.
"RESTful 하다"
1) "/" 슬래시는 계층관계를 나타내는 데 사용한다.
- 여러 리소스의 집합 개념은 복수(-s)를 이용한다. (ex: http://www.example.co.kr/users/newuser )
- 개개의 리소스 엘리먼트는 단수를 이용하여 표현하는 것이 가독성을 높인다. (ex: http://www.example.co.kr/users/newuser )
- URI 는 "/" 로 끝나면 안된다.
2) URI는 가독성이 중요하다
- "_"(언더스코어) 사용 자제
- "-"(하이픈) 사용
- 호스트를 제외한 나머지는 소문자 사용 권장 (RFC 3986 정의)
3) 파일 확장자는 일반적으로 URI에 포함하지 않는다
- 잘 알려진 확장자는 바로 알지만, alz같은 확장자는 한눈에 알아보기 쉽지 않기 때문에 비권장한다
- http://www.example.com/images/main.jpg (△)
- http://www.example.com/images/main accept: image/jpg (o)
4) URI에는 명사 위주로 사용
- GET 요청을 하는데, URI에 동사가 들어간다면(ex: /delete-file) file을 지우라는 모호성을 지닐 수 있어 바람직하지 않다.
REST의 장점
1) 사용이 쉽다: REST API 메세지 자체를 읽기만 하는 것으로 메세지 본래 의도를 파악할 수 있을 정도로 쉽다.
2) 원하는 데이터 표현을 사용할 수 있다:
REST API는
- 헤더부분에 URI에 대한 처리 메소스 명시
- 바디부분에 필요한 실제 데이터를 표현: payload 부분을 json, xml 등 원하는 표현 언어로 사용할 수 있다.
REST의 단점
1) 표준이 없다: REST API는 API설계 가이드일 뿐, 명시적인 표준이 아니다.
2) 구형브라우저에서 지원하지 못하는 Method가 있다.(PUT/ DELETE, pushState)
REST 란?
HTTP라는 기존 웹표준을 사용, HTTP URI로 잘 표현한 리소스(json, xml 등)에 대한 행위를 HTTP method로 정의하는 것.
REST API 란?
HTTP URI로 정의된 리소스(무엇)를 HTTP Method + payload (어떻게)로 잘 정의된 API
REST 구성
1) 자원(resource): URI
- 자원을 구별하는 ID는 HTTP URI다
- 모든 자원은 고유한 ID가 존재하고 자원은 서버에 존재한다
- Client는 URI를 이용해서 자원을 지정하고 자원 상태 조작을 서버에 요청한다
2) 행위(verb): HTTP METHOD
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE등)으로 표현
3) 표현(representations):
- 클라이언트가 자원의 상태(정보) 조작 요청을 하면 Server는 적절한 응답(Representation)을 보낸다
- 하나의 자원은 json, xml, txt 등 여러 형태의 representation으로 나타내어질 수 있다
- json, xml이 일반적
REST API 가이드
REST 특징
1) Uniform interface
URI 리소스 조작을 통일되고 한정적인 인터페이스로 수행
리소스가 문서든, 이미지든, 비디오든 같은 메소드(=HTTP Method)에 의해 다뤄진다
| HTTP Method (일반적인) |
CRUD (Creat/Read/Update/Delete) | |
| POST | 리소스 생성 | create |
| GET | 리소스 조회 도큐먼트에 대한 정보를 가져온다 |
read |
| PUT | 리소스 수정 | update/ replace |
| PATCH | update/ modify | |
| DELETE | 리로스 삭제 | delete |
2) Stateless : 무상태성
작업을 위한 상태정보를 따로 저장하며 관리하지 않는다.
세션이나 정보를 별도로 저장하고 관리하지 않기 때문에, API 서버는 들어오는 요청만 처리하면 된다.
서버에서 불필요한 정보를 관리하지 않아 구현이 단순해진다.
3) Cacheable : 캐시 가능
HTTP 웹표준을 그대로 사용하기 때문에 웹 인프라(ex: 캐싱기능) 적용가능
캐싱구현: HTTP 프로토콜에서 Last-Modified 태그 이용/ E-Tag 이용
4) Self-descriptiveness: 자체 표현 구조
REST API 메세지만 보고, 쉽게 이해 할 수 있는 자체 표현구조로 되어있다.
5) Client-Server 구조
클라이언트: 사용자 인증이나 컨텍스트(세션, 로그인정보)등을 직접 관리
REST 서버: API 제공, 비즈니스 로직 처리 및 저장 책임
각각의 역할이 명확함, 서로간 의존성이 줄어듦
6) Layered System : 계층형 구조
REST 서버는 다중 계층으로 구성 될 수 있다.
구조상 유연성(보안, 로드 밸런싱, 암호화 계층 추가 가능)
cf) URL과 URI의 차이
| URI (= URL(locator) + URN(name)) | URL | |
| Uniform Resource Identifier | Uniform Resource Locator | |
| URL에서 최종 파일 전까지 라고 생각하고있음 | 특정 문서의 위치를 나타냄 |
cf) HTTP 상태코드
참조자료
https://meetup.toast.com/posts/92
http://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=220986337770
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html