대부분의 코드는 작성하는 시간보다 읽히는 시간이 더 많다.
왜냐하면 혼자 개발한다고 해도 내가 지칭한 것 혹은 사용하는 것이 무엇인지 파악해야 하기 때문이다.
코드와 마찬가지로 어플리케이션이 제공하는 API도 신경써서 작성하면 다른 사람들이 API를 활용하기도 수월하고 추후에 본인이 사용한다고 해도 일일이 사용법을 기억할 필요가 줄어들기 때문에 바람직하다고 할 수 있다.

REST (REpresentational State of Transfer)

REST는 REpresentational State of Transfer의 줄임말이다.

위키백과에 의하면 지금 널리 사용되고 있는 WWW(World Wide Web)와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 형식 중 하나이다. 즉, 소프트웨어 아키텍쳐를 어떻게 형성할 것인지에 대한 가이드라인으로 6개의 가이드라인으로 구성되어 있다. 이 6개의 가이드라인을 모두 만족한다면 해당 아키텍쳐를 RESTful이라고 말한다.

웹은 REST를 적용할 수 있는 시스템이기 때문에 웹에서 활용하게 되는 API가 REST의 가이드라인들을 다 따르면 해당 API를 RESTful API라고 부를 수 있다. 전부 충족하지않더라도 큰 의미에서 RESTful API이다라고 부르기도 한다. 즉, 몇몇의 RESTful 아키텍쳐 제약들을 따르게 되는 경우에는 넓은 의미로 봤을 때 REST 아키텍쳐와 비슷한 작동 양상을 보이기 때문에 REST API로 불리게 되기도 한다.

네트워크 아키텍처 원리: 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반

지금의 내 수준에서 작성할 API에소는 REST의 모든 것을 따라야하는 것이 필수조건이 아니다. 그렇기 때문에 HTTP와 관련된 부분을 최소 기준으로 삼아 REST API를 사용해보면서 차차 실력을 쌓아나갈 것이다.

REST API 튜토리얼

REST와 HTTP

웹에서는 HTTP가 주 소통 방법이다.
이 소통 방법에서 서로가 요청을 보내고 응답을 보내게될 때 HTTP 규약에 따라 다양한 요청을 보내고 응답을 받을 수 있다.

여기에 REST 아키텍쳐는 HTTP를 사용할 때 특정 가이드라인들을 제시한다.

웹에서 사용자가 서버에서부터 이미지를 요청한다고 가정해보면 HTTP의 method인 GET이나 POST, 혹은 다른 요청을 보내도 소통에는 문제가 발생하지 않는다. 결과적으로는 어떤 이미지를 볼 수 있기 때문에 서버에 요청된 내용(GET, POST 등)이 다르다고 해도 큰 차이가 없어보인다. 하지만 한 유저가 API를 사용할 때 HTTP의 GET을 사용하여 이미지를 받아왔는데 다른 API에서는 POST를 사용해야한다면 각 API의 활용법이 달라지고 사용할 때마다 각 방식의 사용법을 유의해야한다. 인터넷에 수많은 API가 존재한다는 점에서 각 API가 마음대로 작성되어 있다면 사용자들은 불편하기 마련이다.

그래서 REST 아키텍쳐는 HTTP를 사용할 때 일종의 가이드라인을 제시하여 웹 API가 가져올 수 있는 혼란을 예방하는 데에 기여한다. 하지만 가이드라인인 이상 모든 API가 따르는 것은 아니다.

보통 REST API를 작성했다면 HTTP method는 다음과 같이 사용하기도 한다.

• GET : 데이터 조회
• POST : 데이터 생성
• PATCH : 데이터 업데이트 (데이터 일부 변경)
• PUT : 데이터 업데이트 (데이터 전체 변경)
• DELETE : 데이터 삭제

REST를 활용한다고 하면 HTTP의 특정 방식들을 사용해야하는 것이 아니다.
REST는 아키텍쳐의 형식이기 때문에 HTTP를 직접적으로 간섭하는 것이 아니다.
예를 들어 서버에 있는 데이터를 업데이트 한다고 해서 반드시 PATCH를 사용해야하는 것은 아니다. POST를 사용할 수도 있고 다른 방법으로 작동은 달라도 결과는 같게 만들 수 있다.

하지만 이미 API를 작성하는 사람들 사이에서 일종의 관습으로 행해지는 만큼 해당 HTTP 메소드마다 통용되는 의미가 있다는 부분을 참고하여 공부를 하고자 한다.

HTTP Response

REST에서 주로 사용되는 HTTP 상태코드를 보면 더 도움이 될 수 있다.
기존 HTTP 상태 코드에서 더 사용이 되는 부분들이 있다.
요청을 받았을 때 비슷하게 응답 또한 알맞게 보내야한다. 이 때에도 REST의 가이드라인을 따라 응답을 보내는 방식이 어느 정도 나와있다.

대표적인 상태코드는 아래와 같다.

• 200 (OK)
• 201 (created)
• 202 (accepted)
• 204 (No content)
• 301 (Moved Permanently)

추가: HTTP API vs REST API

이 둘은 사실 거의 같은 의미로 사용된다고 한다.
하지만 디테일에서 차이가 있다고 한다.

HTTP API는 HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고 받으며 통신하는 것으로 상당히 넓은 의미로 사용된다.

반면 REST API는 아래의 4가지 제약 조건이 추가된다.

• 자원의 식별

• 메시지를 통한 리소스 조작

• 자기서술적 메세지

• 어플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

  여러 가지가 있지만 대표적으로 구현하기 어려운 부분은 마지막에 있는 '어플리케이션의 상태에 대한 엔진으로서 하이퍼미디어'이다. 이것은 HTML처럼 하이퍼링크가 추가되어서 다음에 어떤 API르 호출해야하는지 해당 링크를 통해 받을 수 있어야한다.

그리고 이러한 위의 네 가지 조건을 지키면서 개발하는 것을 RESTful API라고 한다. 실무에서는 이러한 방법으로 개발하는 것은 어려운 편이고 추가 개발 비용대비 효과가 있는 것은 아니라고 한다. 하지만 통신 규약을 잘 지킴으로서 코드 해석이나 이해가 더 쉬워지는 효과가 있을 것이다.