오늘 작성하는 RESTful API 글은 유튜버 얄팍한 코딩사전에서 말하는 내용을 요약하고 정리한 글이다.
현재 사용되고 있는 API 설계 규칙 가운데 가장 널리 사용되고 있는 규칙이다.
REST(REpresntational State Transfer)란 웹에 존재하는 모든 자원(resource,이미지,동영상,데이터)에 교유한 URI를 부여하여 자원에 대한 주소를 지정하는 방법론이다.
RESTful API는 REST특징을 지키면서 API를 제공한다는 의미이다.
어떤 기술이나 제품이 아니라 형식이기 때문에 이 형식에 맞춰서 기능을 만들어내면 된다.
과거의 SOAP란 복잡한 형식을 대체한 것이다.
REST의 가장 중요한 특성은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다.
서버에 REST API로 요청을 보낼 때는 HTTP란 규악에 따라 신호를 전송한다.
우체국에서 뭘 부칠 때 일반우편,등기, 택배 등 다양한 방식이 있듯이 HTTP로 요청을 보낼 때도 여러 메소드가 있다. REST API에서는 이 여러 메소드들 중 4가지 혹은 5가지를 사용한다 (GET,POST DELETE ,PUT ,PATCH)
post,put,patch에는 body란 주머니가 있어서 정보를 get이나 delete 보다 더 많이 그리고 비교적 안전하게 감춰서 실어보낼 수 있다.
이것들의 용도가 특정하게 제한되어있지는 않다. 예를 들어 POST하나로도 데이터를 쓰고 읽고 수정하고 지우고까지 다 할 수 있다. 하지만 누구든 각 요청의 의도를 쉽게 파악할 수 있도록 RESTful하게 API를 만들기 위해서는 이들의 목적에 따라 구분
해서 사용해야 된다.
GET: Read, 데이터를 읽는데 사용된다.
POST: Create, 새로운 정보를 추가하는데 사용된다
PUT,PATCH: Update, 정보를 변경하는데 사용되며 업데이트 할 객체를 URI 명기해주며 새 정보들을 body에 실어보낸다.
put과 patch는 쓰는 곳마다 다르고 그냥 put으로 다 하는 경우도 있다. 하지만 정석은 put은 정보를 통째로 변경할 때 사용되고 patch는 정보 중 일부를 특정 방식으로 변경할 때 사용한다.
get으로도 이 4가지가 다 가능하겠지만 이것들로 구분 가능한 요청들을 만들어내려면 URI에 이들의 동작까지 명기해야 된다. 그렇게 되면 정석에 비해 깔끔하지도 않으며 이런 것들을 지양하기 위한 REST의 규칙 중 하나로 URI는 동사가 아닌 명사들로 이뤄줘야 한다는 것이 있다.
결국 REST API란 HTTP 요청을 보낼 때 어떤 URI에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속이다.