REST란, 웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용하는 것으로, 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다.
그리고 Restful API는 REST 특징을 지키면서 API를 제공하는 것을 의미한다. 그런 면에서는 Coding Convention과 비슷하다.
HTTP 의도에 맞게 활용한다는 것은, 첫째, URI는 정보의 자원을 표현해야 하고,
둘째, 자원에 대한 행위는 HTTP Method(GET'생성', POST'조회', PUT'수정', DELETE'삭제')로 표현하는 것을 말한다. 쉽게 말하여, URI로 주어나 목적어를 만들고, HTTP Method로 동사를 만든다는 개념이다.
그러므로, URI를 불분명한 자원으로 표현하거나 혹은 동사처럼 사용하거나, HTTP Method 중 GET을 쓰면서 그것을 활용하여 수정도 하고 삭제를 하는 것은 RESTful하지 않다.
HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.
이는 REST 개념이 대두된 배경과도 연관된다. 첫째, 애플리케이션 복잡도의 증가에 따른 애플리케이션 분리 및 통합이 중요해졌다. 둘째, 모바일과 같은 다양한 클라이언트의 등장하면서 Backend 하나로 다양한 Device를 대응하기 위해 REST의 필요성이 증대되었다.
REST는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다. 즉 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.
HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.
동사(Method) + 명사(URI) 로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 알 수 있으며, 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조로, REST API 메시지만 보고도 이를 쉽게 이해할 수 있다.
클라이언트는 유저와 관련된 처리를, 서버는 REST api를 제공함으로써 각각의 역활이 확실하게 구분되고 일관적인 인터페이스로 분리되어 작동할 수 있게 한다.
URI는 정보의 자원을 표현해야하기 때문에 설계 할때 몇 가지 지켜야 할 것들이 있다.
슬래시 구분자(/)는 계층 관계를 나타내는데 사용
URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
하이픈(-)은 URI 가독성을 높이는데 사용
밑줄(_)은 URI에 사용하지 않는다.
URI 경로에는 소문자가 적합하다.
파일확장자는 URI에 포함하지 않는다.
endpoint 기능
GET /todos List all todos
POST /todos Create a new todo
GET /todos/:id Get a todo
PUT /todos/:id Update a todo
DELETE /todos/:id Delete a todo and its items
GET /todos/:id/items Get a todo item
PUT /todos/:id/items Update a todo item
DELETE /todos/:id/items Delete a todo item
이것도 무슨말인지 하나도 모르겠다가 1차 프로젝트 하면서 API 한번 붙여보고 나니 무슨말인지 대충은 알겠다.
아직은 다 이해할 수 없지만 그래도 한번 보고 두번 보고 세번 보니 좀 다르다.
아직 fetch함수 쓰는 것도 미숙하지만, 2차 때 한번 더 붙여보면 좀 낫지 않을까.
이 포스팅도 2차 끝나고 첨삭 고고.
(GET'생성', POST'조회', PUT'수정', DELETE'삭제')로 잘못된거 같습니다.
Create : 생성(POST)
Read : 조회(GET)
Update : 수정(PUT)
Delete : 삭제(DELETE)