[Web] REST (Representational State Transfer) 정리

REST란?

Representational State Transfer (REST)

- 로이 필딩(Roy Fielding)에 의해 2000년도에 제시된 네트워크 아키텍처 원리의 모음임

- 디자인 원리이기 때문에 특정 프레임워크, 환경, 언어 등에 구애받지 않음

- RESTful : REST의 원리에 충실한 디자인을 지칭할 때 RESTful하다고 표현함

 

REST 구성 요소

- 자원(resource) : URI

- 행위(verb) : 주요 HTTP 메서드 5개(get, post, put, patch, delete)를 주로 사용

- 표현(representation) 

 

REST의 디자인 원칙

1. 인터페이스 일관성

 - 일관적인 인터페이스로 분리되어야 함

 - 요청이 어디서 오는지에 관계없이 같은 표현으로 응답함

2. 무상태(stateless)

 - 요청 시에 필요한 모든 정보를 포함하는 것으로 원칙으로 함

 - 서버측 세션과 각 리퀘스트 사이의 클라이언트 관련 데이터가 필요하지 않음을 의미함

3. 캐시 처리

 - 클라이언트에서 응답을 캐싱할 수 있어야 함 (서버 확장성 증가 및 클라이언트 성능 향상)

4. 계층화

 - 요청과 응답이 서로 다른 계층을 통과하게끔 설계함

 - 클라이언트측에서는 연결되는 서버가 중간 서버(중개자)인지 여부를 알 수 없음

5. 클라이언트/서버 구조로 분리

 - 클라이언트-서버가 독립적으로 개선될 수 있도록 분리(decoupling)해야함

 - 클라이언트는 요청될 리소스의 URI로만 서버와 통신 가능

 - 서버는 클라이언트의 내용을 임의로 변경할 수 없음

6. code on demand (옵션)

 - 정적 리소스를 전송하는 게 일반적이나, 클라이언트 로직(Java 애플릿, 자바스크립트 등)을 포함할 수도 있음

 

REST에서 주로 사용되는 HTTP 메서드 5가지

- GET : 조회(read)

- POST : 요청된 데이터 처리 및 등록 (create)

- DELETE : 리소스 삭제 (delete)

- PUT : 리소스를 대체, 없으면 생성 (update)

- PATCH : 리소스의 일부만 변경 (update)

  * 어떤 메서드를 사용하더라도 데이터의 CRUD가 가능하지만, 각각의 이름에 유의하여 용도에 맞게  적용해야함

  ** 참고로 HTML 폼에서 제공하는 메서드는 GET과 POST밖에 없음. 이전 프로젝트들에서 GET과 POST만 사용하여 CRUD를 전부 수행했던 이유를 이제서야 알게 되었음

사용 예시

- 리액트+스프링부트로 진행 중인 날씨 예보 서비스 프로젝트(기상청 API 사용)

- 프론트(리액트)-백엔드(스프링부트)-기상청API 를 오가며 데이터를 요청 및 전송함

 

프론트엔드(리액트)에서 백엔드(스프링부트)에 요청을 보내는 코드

const [weatherNow, setWeatherNow] = useState({baseDate: "-", baseTime: "-", pty: "-", reh: "-", rn1: "-", t1H: "-", uuu: "-", vec: "-", vvv: "-", wsd: "-", sky: "-"});

  useEffect(()=>{

    axios.get('http://localhost:8080/api/weatherNow')
    .then((result)=>{ setWeatherNow(result.data) })
    .catch(()=>{ console.log("통신실패"); })

  }, [])

- axios.get : axios를 사용하여 GET 방식으로 호출하겠다는 의미 (행위)

- 'http://localhost:8080/api/weatherNow' : localhost:8080 (백엔드 주소)을 호출하여 api 중 weatherNow (현재 날씨 정보)에 해당하는 정보를 받아옴 (자원)

- 호출에 대한 응답 예시 : 데이터형태(json), 상태코드(200) 등과 함께 data 안에 요청에 따른 응답 데이터 표기 (표현) 

 

스프링부트에서 기상청 API를 호출할 때도 이런식으로 HTTP 메서드 이름(GET)과 응답 표현(json)을 지정하여 보냄

HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod("GET");
conn.setRequestProperty("Content-type", "application/json"); 

return conn;

 

응답결과

위 요청에 대한 응답을 웹브라우저 콘솔에 출력한 내용

 

- 순서를 정리해보면 '리액트에서 스프링 호출 -> 스프링에서 기상청 API 호출 -> 기상청 API에서 스프링에게 응답 -> 스프링에서 데이터 파싱 및 가공 -> 스프링에서 리액트에게 응답' 순으로 작업이 이루어짐

 

응답으로 전달된 데이터를 표기 (현재 날씨)

Note

엄격한 의미에서의 REST에 부합하는 API가 생각보다 많이 없고, 로이 필딩은 이런 API들에 대해 HTTP API로 명명할 것을 제안했다고 한다. REST에 부합한 API 설계를 위해서는 응답 데이터의 용도에 대한 명세를 문서화한다던지, 셀프 링크를 추가하여 동적인 상태 변경으로 이어질 수 있도록 해야한다던지 충족시켜야할 조건들이 많다. 그런 의미에서 이제까지 수행했던 프로젝트들과 이번 날씨예보 서비스 프로젝트에서 내가 만들고 있는건 REST API라고 하기가 조금 어렵다. 나중에 좀 더 자세하게 다뤄봐야겠다.