글 작성 계기
졸업작품을 하면서 설계한 API 에 대해서 고민을 하던 중, RESTful 에 대해 잘 모르는 것 같아서 제대로 공부 및 정리를 해보기로 하였다.
우리 팀에서는 유저의 지역 인증 로직을 다음과 같이 put 메서드로 구현을 해두었다.
@**PutMapping**("/region")
public ResponseEntity<RegionUpdateResponse> updateRegion(@Login Long memberId, @Valid @RequestBody RegionUpdateRequest regionUpdateRequest) {
Region updateRegion = memberService.updateRegion(regionUpdateRequest, memberId);
return ResponseEntity.ok()
.body(new RegionUpdateResponse(updateRegion.getValue()));
}이후 유저의 Alias 와 Region을 둘다 바꿔야 하는 상황이면 어떤 HTTP Method 를 사용해야하지? 라는 의문과 함께 put 과 patch 에 대해서 혼동이 있는 상황을 인지를 했다. 그래서 코드살롱 분들에게 다음과 같이 질문을 올렸다.
질문 내용
사실상 혼자 자문 자답해버림,, 근데 애매하게 아는건 모르는거지 뭐…
이후 Restful 에 대해서 공부 및 정리 해보고, 공부한 내용을 반영해 답을 내리라는 조언을 얻었고 바로 공부하기로 했다.
REST API (RESTful API) 란
- 2000년에 로이 필딩의 논문에서 최초로 소개되었다.
- 웹 서비스 의 개발 흐름은 단순히 한두개의 브라우저만 지원하면 되었던 과거와 달리, 다양한 브라우저 더 나아가 안드로이드, IOS 애플리케이션과의 통신에 대응이 되어야 했다.
- 따라서 범용적으로 적용 가능하고 사용성이 좋은 API 디자인이 필요하게 되었음
- 당시 웹(HTTP) 설계의 우수성을 최대한 활용할 수 있도록 고안된 아키텍처이다.
RESTful API 를 사용하는 이유
- 모바일, PC, 어플리케이션 등 플랫폼에 제약을 두지 않기 때문
- 다양한 기기(TV, 스마트폰, 태블릿, pc) 등이 등장하면서
Client Side를 고려하지 않고, Client에서 바로 객체 치환 가능한 형태의 데이터 통신을 지향하게 되면서Server 와 Client의 역할을 분리하게 되었고, 서버에서RESTful API 형식의 통신을 하면 각 클라이언트에서는 이를 각각 처리 가능 하게 됨.
REST 의 구성
REST API 는 세가지의 구성으로 이루어져있다.
- 자원(Resource) : URI
- 행위 (Verb) : HTTP method
- 표현 (Representations)
하나씩 뜯어보자.
자원
- 모든 자원에는 고유한
ID가 존재하고 이 자원은 Server에 존재한다. - ID는 HTTP URL를 의미한다. →
/board/1
행위
- HTTP 프로토콜의 Method 를 의미한다.
- HTTP 프로토콜은
GET,POST,PUT,DELETE,PATCH등이 있다.GET- 리소스의 표시를 요청POST- 특정 리소스의 생성DELETE- 특정 리소스의 삭제PATCH- 리소스의 부분을 변경
표현
- Client 가 자원의 상태(정보) 에 대한 조작을 요청하면 Server 는 이를 수행하고 응답 (Repressentation) 을보낸다.
- REST 에서의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 응답으로 표현이 가능하다.
정리하자면 REST API 는 HTTP URI 를 통해 자원을 명시하고, HTTP Method ( Post, Get, Put, Delete) 를 통해서 해당 자원에 대한 CRUD 작업을 적용한다.
REST API의 특징
1. 클라이언트 / 서버 구조
- 클라이언트는 유저와 관련된 처리를하고, 서버는 REST API를 제공하여 각각의 역할을 분리하여 일괄적인 인터페이스로 작동하게 한다.
2. Stateless(무상태성)
REST는 무상태성을 갖는다. 즉 상태정보를 저장하고 관리를 하지 않는다. 이는 HTTP 프로토콜의 특성을 이용하기 때문.- 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만 처리를 하면된다.
3. 캐시 처리 가능
- HTTP 라는 기존 웹 표준을 사용하는 REST 의 특징 때문에 기본 웹에서 사용하는 인프라를 그대로 사용함.
- 대량의 요청을 효율적으로 처리를 하기 위해 캐시가 요구되는데, 이런 캐시 사용을 통해 응답 시간이 빨라지고, REST server의 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있음.
4. 자체 표현 구조
REST API메세지만으로 해당 요청이 어떤 행위를 하는지 알 수 있다.GET /api/board→ 1번 게시글 조회
5. 계층화
- 클라이언트와 서버가 분리 되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 활용 할 수 있는 측면에서 자유도가 높다.
6. 유니폼 인터페이스
Uniform Interface는Http표준을 따르면 모든 플랫폼에서 활용가능하다. 이때URI로 지정한 리소스에 대한 조작을 가능하게 한 아키텍처 스타일을 말한다.URI로 지정한 자원에 대해 조작을 통일되고 한정적인 인터페이스로 수행- 즉, 특정 언어나 기술에 종속되지 않는다.
결론
결론적으로 RESTful 한가? 라는 질문은 다른 말로 REST API에 맞게 데이터를 주고 받는가? 라는 질문으로 바뀔 수 있다.
즉 어떠한 자원을 보내거나, 요청 할때 REST API 에 맞게 데이터를 주고 받으면, 다양한 브라우저 어플리케이션에 종속되지 않는 서비스를 만들 수 있다.
또한 HTTP 프로토콜을 따르기 때문에 최대한의 인프라를 활용 할 수 있다는 장점도 있다.
무엇보다 협업의 측면에서 Clinent 와 Backend 혹은 개발자들 사이에서 URL 만 보고도 해당 요청이 어떤 자원을 어떤 행위로 처리를 해야하는지 알 수 있다.
답변
이 질문에 대한 나의 답은
- alias 하나만 변경
- region 하나만 변경
- alias, region 변경
모두 리소스(유저)의 일부분만 변경하기 때문에 patch를 써야하고, 이를 RESTful 하게 처리하기 위해서는
patch /member/alias/{userId}
patch member/region/{userId} 등의 형태로 처리를 해야겠다고 생각한다.
