
백엔드 공부하면 API 관련해 무조건 보이는게 'REST API'다. 처음에 너무 개념이 모호한 느낌이었는데, 공부하다 보니 왜 중요한지 좀 알 것 같았다.
REST란 Representational State Transfer의 약어로, 클라이언트와 서버간 통신 방식 중 하나다. 클라이언트와 서버는 기본적으로 '자원'을 주고 받으며 통신하는데, REST는 자원을 이름으로 구분해 해당 자원의 정보를 주고 받는 것을 의미한다.
- 자원: 소프트웨어에서 관리하는 모든 것으로, 문서, 그림, 데이터 등이 있다.
- 이름: 해당 자원을 표현하고자 하는 것으로, 유저의 정보가 자원이라면 'user'를 유저 정보에 대한 '이름'으로 정한다.
상태 전달의 경우 데이터가 요청되는 시점에 자원의 상태, 즉 정보를 전달한다. json, xml을 통해 전달한다.
HTTP URI를 통해 자원을 명시하고, HTTP 메서드를 통해 자원에 대한 CRUD를 적용하는 것이 RESTful한 API라고 할 수 있다.
HTTP 메서드는 아래와 같다.
- POST => Create
- 자원을 새로 추가할 때 사용
- GET => Read
- 자원의 상태를 받아올 때 사용
- PUT => Update
- 존재하는 자원을 전체적으로 변경할 때 사용
- Patch => Update
- 한 자원의 데이터를 부분적으로 변경할 때 사용
- DELETE => Delete
- 자원을 삭제할 때 사용
내 Spring 프로젝트에 빗대어 예를 들자면, '일정'이라는 자원에 대해 'schedule'이라는 이름을 가지고 클라이언트와 서버가 통신할 예정이다.
uri에는 자원의 이름을 가져야 하고, schedule이라는 자원 request에 메서드와 매핑해서 처리해야하므로 일정 컨트롤러 계층에서 아래의 애노테이션을 붙여줬다.
...
@RequestMapping("/api/schedule")
public class ScheduleController { ...
그리고 일정에 대해 생성/수정/조회/삭제 (CRUD) 연산을 진행해야 한다. 각 연산에 대해서는 Post, Patch, Get, Delete 메서드를 사용했다.
@PostMapping
public Schedule createSchedule(...){ ...}
@PatchMapping
public Schedule editSchedule(...){...}
@GetMapping
public Schedule getSchedule(...){...}
@DeleteMapping
public void deleteSchedule(...){...}
일정 수정은 하나의 일정에 대해 일부가 수정되므로 Put보단 Patch가 적합했다.
- 장점
1. REST API 메세지가 의도하는 바를 확실히 나타내므로 의도를 쉽게 파악할 수 있다.
- 서버와 클라이언트의 역할을 명확히 분리할 수 있다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- 단점
1. 사용할 수 있는 메서드가 제한적이다.
- 표준이 존재하지 않는다.
- 구형 브라우저에서는 아직 제대로 지원해주지 못하는 부분이 있다. (PUT,DELETE 사용 불가 등)