[첫번째 프로젝트] 2. API

0. 식당으로 알아보는 API

흔히 있는 식당에서 식사한 경험을 떠올려보세요. 일반적으로 고객이 식당에 들어가면 점원에게 요리를 주문합니다. 그리고 점원은 주방에 가서 '요리를 만들어 주세요.'라고 요청하죠. 그리고 요리가 완성되면 다시 점원이 손님에게 요리를 전달합니다.

여기서 고객은 클라이언트, 주방에서 일하는 요리사를 서버라고 생각하면 됩니다. 그리고 중간에 있는 점원을 API라고 생각하면 되죠! 이 상황에 적용해서 생각해봅시다. 우리는 웹 사이트의 주솔르 입력해서 '구글 메인 화면을 보여줘!' 라고 요청을 할 겁니다. 그러면 API는 이 요청을 받아서 서버에게 가져다줍니다. 그러면 서버는 API가 준 요청을 처리해 결과물을 만들고 이것을 다시 API로 전달하죠/ 그러면 API는 최종 결과물을 브라우저에 보내주고 여러분은 화면을 볼 수 있게 됩니다. 이처럼 API는 클라이언트의 요청을 서버에 잘 전달하고, 서버의 결과물을 클라이언트에게 잘 돌려주는 역할을 합니다. 그렇다면 REST API는 무엇일까요?

1. REST API

REST API는 웹의 장점을 최대한 활용하는 API입니다. REST는 Representational State Transfer의 줄인 표현으로 풀어서 말하면 자원을 이름으로 구분해 자원의 상태를 주고받는 API 방식입니다. 쉽게 말해서 명확하고 이해하기 쉬운 API를 말합니다. 보통 처음에 REST API라는 말을 들으면 우리가 배우는 스프링 부트나 리액트, Vue.js와 같은 기술이라고 착각하기 쉬운데요, REST API는 URL의 설계 방식을 말합니다. 그래서 이 설계 방식을 따랐을 때 얻을 수 있는 개발자 입장에서의 장점이 있고, 또 단점이 있습니다. 그럼 REST API가 무엇인지 자세히 알아볼까요?

1.1 REST API의 특징

REST API는 서버/클라이언트 구조, 무상태, 캐시 처리 기능, 계층화, 인터페이스 일관성과 같은 특징이 있습니다. 지금 당장은 이 특징을 모두 이해할 필요는 없습니다. 지금 당장은 이런 것들이 있구나 정도만 이해하고 추후에 웹을 학습할 때 자세히 찾아보는 것을 추천합니다!

1.2 REST API의 장점과 단점

REST API의 장점은 URL만 보고도 무슨 행동을 하는 API인지 명확하게 알 수 있다는 것입니다. 그리고 상태가 없다는 특징이 있어서 클라이언트와 서버의 역할이 명확하게 분리됩니다. 그리고 HTTP 표준을 사용하는 모든 플랫폼에서 사용할 수 있죠. 단점으로는 HTTP 메서드, 즉, GET, POST와 같은 방식의 개수에 제한이 있고, 설계하기 위해 공식적으로 제공되는 표준 규악이 없다는 겁니다. 그럼에도 REST API는 주소와 메서드만 보고 요청의 내용을 파악할 수 있따는 강력한 장점이 있어 많은 개발자들이 사용합니다. 심지어 'REST하게 디자인한 API'를 RESTful API라 부르기도 합니다. 그러면 REST API는 어떻게 사용할까요?

1.3 REST API 사용하는 방법

• 규칙 1. URL에는 동사를 쓰지 말고, 자원을 표시해야 한다.

  URL는 자원을 표시해야 한다는 말에서 자원은 무엇을 말할까요? 자원은 가져오는 데이터를 말합니다. 예를 들어 학생 중에 id가 1인 학생의 정보를 가져오는 URL는 이렇게 설계할 수 있습니다.

  ./students/1
  ./get.student?student_id=1

  처음에 이 URL을 보면 '어떻게 해도 괜찮은 것 아닐까?'라고 생각할 수도 있을텐데요. 하지만 REST API에 더 맞는, 그러니까 RESTful API는 1번입니다. 왜냐하면 2번의 경우 자원이 아닌 다른 표현을 섞어 사용했기 때문이죠. 2번의 경우 동사를 사용해서 추후 개발 시에 혼란을 줄 수 있습니다. 예를 들어 서버에서 데이터를 요청하는 URL을 설계할 때 어떤 개발자는 get을 어떤 개발자는 show를 쓰면 어떻게 될까요? 그러면 URL의 구조가 get-student, show-data와 같이 엉망이 될 겁니다. 행위는 '데이터를 가져온다'지만 표현이 중구난방이 될테니 말이죠. 그래서 RESTful API를 설계할 때는 이런 동사를 쓰지 않습니다.

  예문	적합성	설명
  /articles/1	적합	동사 없음, 1번 글을 가져온다는 의미가 명확, 적합
  /articles/show/1 /show/articles/1	부적합	show라는 동사가 있음, 부적합

• 규칙 2. 동사는 HTTP 메서드로

  앞서 동사에 대해 이야기했죠. 이건 HTTP 메서드라는 것으로 해결합니다. HTTP 메서드를 앞서 몇 번 언급했는데 여기서 아마 많은 의문이 풀릴 거라 생각합니다. HTTP 메서드는 서버에 요청을 하는 방법을 나눈 것인데요, 주로 사용하는 HTTP 메서드는 POST, GET, PUT, DELETE입니다. 각각 만들고(Create), 읽고(Read), 업데이트하고(Update), 삭제(Delete)하는 역할을 담당하는데요. 보통 이것들을 묶어서 크루드(CRUD)라고 부릅니다. HTTP 메서드의 감을 잡기 위해 블로그에 글을 쓰는 설계를 한다고 생각해보겠습니다. 그럼 이런 설계를 생각해볼 수 있는데요. 같은 URL이라도 역할이 다른 것을 볼 수 있습니다.

  설명	적합 HTTP 메서드와 URL
  id가 1인 블로그 글을 조회하는 API	GET /articles/1
  블로그 글을 추가하는 API	POST /articles/1
  블로그 글을 수정하는 API	PUT /articles/1
  블로그 글을 삭제하는 API	DELETE /articles/1

이외에도 슬래시는 계층 관계를 나타내는데 사용하거나, 밑줄 대신 하이픈을 사용하거나, 자원의 종류가 컬렉션인지 도큐먼트인지에 따라 단수, 복수를 나누거나 하는 등의 규칙이 있지만 지금 당장은 이 정도만 알아도 충분합니다!