REST란?
★REST(Representational State Transfer) : HTTP프로토콜을 기반으로한 분산 시스템에서의 통신을 위한 아키텍쳐 스타일(규칙들의 집합) 중 하나. RESTful API란 이 아키텍쳐 스타일을 따르는 API라는 의미이다. 이 아키텍쳐 스타일을 따름으로써 서버와 클라이언트의 종류에 관계없이 일관된 통신이 가능하게 되고, 필요한 데이터만을 보낼 수 있게 되어 좀 더 가벼운 통신이 가능해 졌다.
★REST의 구성요소
- 자원(Resource) : 자원의 식별자인 URI로 표현한다.
- 행위(Verb) : 자원(목적어)에 대한 행위(동사)를 METHOD(GET, POST, PUT, DELETE)로 표현한다.
- 표현(Representation) : 자원에 대한 행위의 결과를 표현하는 방식을 MIME type(Json, XML…)으로 표현한다.
★REST 스타일을 구성하는 규칙들
- 서버-클라이언트 구조 : 클라이언트는 서버에 자원의 조작을 요청한다.
- Stateless(상태 없음) : 세션이나 쿠키와 같은 Context정보는 서버에 저장되지 않고, 오직 요청의 내용으로만 요청을 처리한다. 즉 클라이언트의 각 요청들은 완전히 독립적이다.
- Cacheable(캐싱 가능) : 클라이언트는 서버의 응답을 캐시에 저장해 둘 수 있다. 서버에 어떠한 요청을 보내 받았던 정보를 캐시에 저장해 뒀다가 다음번에 같은 요청을
Last-Modified
태그와 함께 보냈을 때 서버는 컨텐츠의 변화가 없다면304 Not-Modified
메시지를 클라이언트에 돌려주고, 이 메시지를 받으면 클라이언트는 캐시에 저장된 데이터를 사용함으로써 훨씬 효율적인 데이터 교환이 가능하다. - Layered System(계층 구조) : 서버는 다양한 계층 구조로 구성될 수 있으나 서버의 구조에 관계없이 클라이언트는 항상 같은 방식으로 요청할 수 있어야 한다.
- Self-descriptiveness(자체 표현 구조) : 주고 받는 API메시지 만으로도 이를 이해할 수 있다.
- Uniform Interface(일관된 인터페이스) : URI는 자원을 식별하는 유일한 식별자이고, 자원에 대한 행위를 유한하게 통일한다. 이렇게 딱 정해 놓음으로써 플랫폼에 관계없이 같은 방식으로 API의 이용이 가능하다.
★REST API METHOD : 자원에 대한 행위는 다음의 4가지 중 하나를 사용한다.
- POST(Create) : URI를 요청하여 리소스를 생성한다.
- GET(Read) : URI에 해당하는 리소스를 조회한다.
- PUT(Update) : URI에 해당하는 리소스를 수정한다.
- DELETE(Delete) : URI에 해당하는 리소스를 삭제한다.
★면접 단골 질문 GET과 POST의 차이는?
- GET : 클라이언트가 입력한 query의 이름과 값이 URI형태로 전달된다. -> 데이터를 URI의 길이 한도내에서만 전송할 수 있다. -> DB에 추가적인 정보처리를 요구하지 않고 단순히 데이터 요청용도로만 사용한다.
- POST : 클라이언트가 입력한 Data가 헤더를 통해, Query가 body를 통해 전달된다. -> 데이터의 양에 제한이 없다. -> DB에 추가적인 데이터 작업을 할 때 사용한다.
★REST API URI : 자원에 대한 식별자이다.
- URI에는 행위에 대한 내용은 들어가지 않는다. (행위는 Method로 표현한다)
/
는 자원의 계층 구조를 나타낼 때 사용한다. ex) localhost:8080/mobiles/android- URI의 마지막에
/
를 붙이지 않는다. - URI의 가독성을 위해
_
대신-
를 사용한다. - URI에 대문자를 넣지 않는다.
- 확장자는 URI에 포함시키지 않는다.
- 자원간의 관계는
리소스명/리소스ID/관계가있는 다른 리소스명
형식으로 나타낸다 - Document는 자원객체를 말하고 Collection은 객체들의 집합을 말한다. 예를 들어 phones가 Collection이라면 iphone은 Document라 할 수 있다. 이 경우
localhost:8080/phones/iphone
으로 표시할 수 있는데 Collection은 복수형 명사로 표기한다.