Representation State Transfer
하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정
웹의 장점을 최대한 활용할 수 있는 아키텍처(설계구조)로써 REST를 발표
HTTP URL를 통해 제어할 자원을 명시하고 HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원을 제어하는 명령을 내리는 방식의 아키텍처
REST 구성
- 자원(Resource) : URI(URL/URN)
- 행위(Verb) : HTTP Method
- 표현(Representations)
- 위 세가지를 결합해서 하나의 주소를 쓰는 것.
- 잘 표현된 HTTP URI로 리소스를 정의하고 HTTP Method로 리소스에 대한 행위를 정의
- 리소스는 JSON, XML과 같은 여러가지 언어로 표현 가능
기존 웹 접근 방식과 REST API 방식의 차이점
- 기존 접근 방식 : GET과 POST만으로 자원에 대한 CRUD를 처리, URI는 액션
- REST로 변경할 경우 위 4가지 메서드를 모두 사용하여 CRUD 처리. URI를 제어하려는 자원을 나타냄
API
- API유형
- 프라이빗 API
- 기업 내부에 있으며 비즈니스 내에서 시스템과 데이터를 연결하는데 사용
- 퍼블릭 API
- 일반인에게 공개, 모두 사용 가능
- 단, 사용에 대한 권한 설정과 비용 발생 가능
- 공공데이터 포털, 기상청, Naver, Kakao, Youtube 등
- 대부분 REST방식으로 작성
- 프라이빗 API
REST API
- REST+API
- 기존의 전송방식과는 달리 서버는 요청받은 리소스에 대해 순수한 데이터를 전송
- 원래는 페이지를 보냈음
- 기존의 GET/POST 외에 PUT, DELETE 방식 사용하여 리소스에 대한 CRUD 처리 가능
- HTTP URI를 통해 제어할 자원 명시하고, HTTP METHOD를 통해 해당 자원을 제언하는 명령을 내리는 방식의 아키텍처
- 가장 큰 단점은 딱 정해진 표준이 없어서 다들 이렇게 쓰더라 하는 암묵적인 표준만 정해져 있음
- 하이픈(-)은 사용 가능하지만 언더바(_)는 사용X
- 특별한 경우를 제외하고 대문자 사용은 X
- URI마지막에 /사용X
- /로 계층관계 구분
- 확장자가 포함된 파일을 직접 포함시키지 않음
- URI는 명사를 활용
기존 Service 와 Rest API Service
- 기존 : 요청에 대한 처리를 한 후 가공된 data를 이용하여 특정 플랫폼에 적합한 형태의 View를 만들어서 반환
- REST Service : data처리만 한다거나, 처리 후 반환될 data가 있다면 JSON이나 XML형식으로 전달, View에 대해서는 신경 쓸 필요가 없음 → 이런 이유로 Open API에서 많이 사용
Restful
- REST API로 구축된 웹 서비스
- request : GET/POST/PUT/DELETE + URI
- response : XML/JSON
