웹 상에서 존재하는 모든 자원에 고유한 의미를 부여하여 활용 하는 것
REST(REpresentational State Transfer)은 네트워크 상에서 서버와 클라이언트 사이의 통신방식 중 하나로, 자원을 이름으로 구분하여 해당 자원의 정보(상태)를 주고받는 모든것을 의미한다.
REST의 구성은 자원(URI), 행위(HTTP 메소드), 표현(XML/Json)으로 되어있다.
💡 그렇다면 RESTful한 API는 무엇일까? RESTful하게 API를 디자인하라는 말은 도대체 무엇을 뜻하는 것일까..? 코딩을 하다보면 이러한 말들을 종종 들을 수 있는데 이것은 과연 어떤말일지 한 번 생각해보자.
나는 위의 질문의 핵심은 말 그대로 RESTful의 설계 규칙을 올바르게 지킨 API이냐고 물어보는것이라 생각한다. 이 말의 뜻을 정확히 알려면 RESTful의 설계 규칙도 잘 알고 있어야 된다는 생각이들어 아래에 정리해 보았다.
HTTP 프로토콜 기반이다
자원(리소스)는 URI(Uniform Resource Identifiers)로 표현한다 -> 고유함
URI는 직관적인 구조로 단순하게 표현된다
자원의 상태는 HTTP 메서드를 활용해서 구분한다
XML / Json을 활용하여 데이터를 전송한다 -> 주로 Json 사용
✨ 그럼 이제 REST와 RESTful하게 API를 디자인하는 규칙도 알았으니 한 번 만들어볼텐데 그 전에 꼭 기억해야할 두 가지 항목이 있다. 아래의 항목을 바탕으로 만들어보자.
URI는 정보의 자원을 표현해야한다. (자원명은 v보다는 복수n를 사용함)
자원에 대한 행위는 HTTP 메서드로 표현해야한다.
HTTP 메서드는 GET을 이용하였고, 등록되어있는 회원1을 삭제하는 URI이다. 그런데.. 어딘가 어색하다⁉
GET /members/delete/1
왜 members에 있는 회원1을 삭제하는데 GET을 사용했을까?
delete라는 행위에 대한 표현이 URI에 들어가는게 맞는건가?
여기서 알아야할점은 HTTP 메서드는 상황에 따라 알맞은 메서드를 사용해야 한다는것과, URI는 자원을 표현하는데 중점을 두어야 해서 delete와 같은 행위에 대한 표현이 들어가서는 안된다는것이다. 자원에 대한 행위는 HTTP 메서드로 표현해야한다. 다시 수정해보자.
DELETE /members/1
마음이 편안하다😇 회원정보를 삭제하는 URI를 만들어봤으니 회원정보를 가져오거나 추가하는 URI는 어떻게 만들어야할지 감이 온다.
GET /members/2 //가져오기
POST /members/3 //추가하기
이제 HTTP 메서드(CRUD)에 대해 슬쩍 알아보고 마무리해보자.
데이터를 관리하는 큰 틀의 약자
CRUD 각각의 의미는 아래와 같다.
보통 오른쪽 가로 안에 적혀진 HTTP 메서드
(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하게된다.