Chapter02. Spring Boot - Restful API 이론

<< 학습 목표 >>

1. API를 설명할 수 있다.

2. REST 아키텍처(개발 방식)에 대해서 설명할 수 있다.

3. RestfulAPI에 대해서 설명할 수 있다.

---

API란?

API는 Application Programming Interface 로 다른 소프트웨어 시스템과 통신(요청/응답) 하기 위한 프로그램임

쉽게 말해 API는 컨트롤러임

 

햄버거 가게의 메뉴 정보를 보여주는 화면(프론트엔드)가 다음과 같이 세 가지가 있다고 하자

웹사이트, 키오스크는 보여줄 메뉴 정보를 웹사이트, 키오스크에 저장해둔 상태로 만들 순 있지만 핸드폰의 경우는 그럴 수 없음

우리 핸드폰 살 때 맥도날드 메뉴 정보가 들어있었는지?

롯데리아 메뉴 정보가 들어있었는지?

당연히 들어있지 않음

 

또한 메뉴 정보는 언제든 바뀔 수 있기 때문에 웹사이트, 키오스크에 저장해둔 상태로 만든다는건 좋지 못함

 

그래서 화면에 필요한 메뉴 정보를 전달해 줄 컨트롤러(API)가 필요함

 

 

이때 클라이언트에게 필요한 정보 또는 데이터를 리소스(Resource/자원) 라고 부르고 정보 또는 데이터를 보여주는 화면을 클라이언트(Client) 라고 부름

컨트롤러는 클라이언트와 리소스 사이에 위치하면서

클라이언트가 자신에게 필요한 데이터(리소스)를 얻기 위한 관문이므로

컨트롤러는 게이트웨이(Gateway) 라고 생각하면 됨

---

REST란?

"API는 이렇게 동작해야한다" 라고 정의 해놓은 약속

 

약속1. 일관되게 API를 구현해야함

  - 이를 위해

    > 모든 리소스는 고유의 URI(Uniform Resource Identifier) 를 가져야함
       리소스가 무엇인지는 바로 윗 문단에서 설명했음

       리소스를 직역해서 자원이라고 표현하기도 함

    > 클라이언트는 올바른 방식(Method / GET, POST, DELETE, PUT ) 을 사용해 서버로 요청해야하고 서버는 요청 방식에 맞는 처리를 제공해야함

약속2. 무상태성을 가져야함

  무상태성에 대해서 이해하려면 HTTP 프로토콜에 대해서 찾아보기

약속3. 계층화된 시스템(Layered System)이어야함

  계층화(Layered / 레이어드) 는 일상 생활에서도 흔히 쓰이는 말로 "옷을 레이어드 해 입었다" 란 말은 옷 위에 옷을 입은 것으로 안에 옷만 바꿔 입으면 다른 패션이 되고 바깥 옷만 바꿔 입으면 또 다른 패션이 되는 것처럼 API가 동작하는 시스템은 계층화된 시스템이어야함

  API가 동작하는 시스템이 계층화 되어있다는건 API에 필요한 추가 사항을 추가하기 쉬운 환경이라는 것임

 가령 로그인 API를 만들고 3개월까지는 문제 없이 동작했는데 4개월 째에 로그인을 하면 해커가 로그인 정보를 빼돌린다는 걸 알았음

  이때 클라이언트의 요청이 로그인 API로 도달하기 전(보통 앞, 앞단이라고 표현함) 또는 후(보통 뒤, 뒷단이라고 표현함)에 보안 관련 기능이 동작하도록 추가 사항을 추가 할 수 있는 환경을 만들었다면 계층화된 시스템이라고 함

  단, 클라이언트는 자신이 요청한 것만 알고 요청한 것 이외에는 몰라야함

  위에서 예를 든것처럼 클라이언트는 로그인 API를 요청했는데 "로그인 API로 요청이 들어가기 전에 보안 관련 기능이 동작한다" 라는걸 클라이언트는 알면 안됨

약속4. 서버는 캐싱 처리 응답을 할 수 있어야하고 클라이언트는 캐싱 처리를 할 수 있어야함

  웹 사이트 로고 이미지가 있을 때 클라이언트가 로고 이미지를 매번 다운 받아 보여주면 비효율적임

  서버가 캐시 가능으로 응답했다면 클라이언트는 로고 이미지를 최초에 한번만 다운 받아 저장해두고 다음부터는 캐시에 저장된 로고 이미지 파일을 보여줘야함

  보통 서버는 응답 헤더에 Last-Modified 태그나 E-Tag 에 캐시 가능, 불가능을 담아 보냄 

---

RESTfulAPI란?

REST 기반의 API를 RESTfulAPI라고 함

REST, REST API, RESTfulAPI 모두 같은 말이므로 혼용해서 사용해도 됨

 

RESTfulAPI는 요청 방법(Method)와 URI, 상태코드를 적극 활용해야함

 

<< 요청 방법 >>

요청 방법에는 GET, POST, PUT, DELETE이 있음

- GET : 클라이언트가 리소스를 요청할 때 사용하는 방식

- POST : 클라이언트가 리소스를 생성할 때 사용하는 방식

- PUT : 클라이언트가 리소스를 수정할 때 사용하는 방식

- DELETE : 클라이언트가 리소스를 삭제할 때 사용하는 방식

예를 들어 클라이언트가 이미지를 요청 할 때 GET 방식으로 요청함 또는 회원 정보를 조회할 때 GET 방식으로 요청함

클라이언트가 이미지를 업로드 할 때 POST 방식으로 요청함 또는 회원 가입을 할 때 POST 방식으로 요청함

클라이언트가 업로드한 이미지를 수정할 때 PUT 방식으로 요청함 또는 회원 정보를 수정할 때 PUT 방식으로 요청함

클라이언트가 업로드한 이미지를 삭제할 때 DELETE 방식으로 요청함 또는 회원 탈퇴를 할 때 DELETE 방식으로 요청함

 

 

<< URI >>

URI는 Uniform Resource Identifier의 약자로 리소스를 식별할 수 있는 식별자를 뜻함

식별자란 말이 낯선데 Identifier 가 우리말로 식별자이고 Identifier 의 앞 두 자 id (아이디) 는 익숙할 것

어떤 서비스에 가입할 때 항상 id (아이디) 를 입력하는데 id가 Identifier에서 나온 것

또 현실 세계의 우리도 식별자를 갖고 있음

주민등록번호 또는 연락처

주민등록번호 또는 연락처로 사람 한 명 한 명을 식별할 수 있음

 

여기서 URL과 URI 두 가지가 있고 이 두 가지를 헷갈려하는 분들이 많음

URL은 Uniform Resource Locator의 약자로 리소스의 위치를 뜻함

 

가령 우리가 만든 서버 컴퓨터의 IP 주소가 192.168.0.1 이고 서버 컴퓨터에는 톰캣이 8080번 포트로 열려있음

또한 톰캣에는 studyproject가 위치해있는 상황이라고 하자

studyproject로 접근하기 위한 경로(URL)은 http://192.168.0.1:8080/studyproject 임

studyproject 내 chapter04 폴더 안에 image1.png 이미지가 있다면

  - 이 이미지의 URL은 http://192.168.0.1:8080/studyproject/chapter04/image1.png 임

  - 이 이미지의 URI는 /chapter04/image1 임

여기서 주의할 점 URI는 URL에 포함되어있음

따라서 http://192.168.0.1:8080/studyproject/chapter04/image1.png 는 URL도 되고 URI도 됨

그러나 /chapter04/image1 은 URL은 될 수 없고 URI는 될 수 있음

 

URI는 일반적으로 파일의 확장자는 표시하지 않음

따라서 헷갈린다면 http로 시작하거나 경로의 가장 마지막에 파일의 확장자가 있다면 URL

http로 시작하지 않거나 경로의 마지막에 확장자가 없다면 URI 라고 생각하면 됨

 

예전에는 면접에서 URL, URI 를 물어보는 곳이 많았지만 요즘에는 더 필요하고 중요한 기술들이 많아졌기에 물어보는 곳은 드물 것

알고 있으면 개발에 도움되는 상식 정도임

 

 

<< 상태 코드 >>

상태 코드는 영어로 Status Code 이고 가끔 응답 코드 (Response Code) 라고도 부름

상태 코드는 서버가 클라이언트에게 하는 응답이 어떤 상태인지를 나타냄

이를 활용하면 최소한의 데이터로 서버가 어떤 응답을 하는지 클라이언트에게 전달 할 수 있음

 

상태 코드는 100, 200, 300, 400, 500번대가 있으며 가장 많이 사용하는 상태 코드는 200, 400, 500번대임

상태 코드는 쉬우면서 이미 인터넷에 잘 나와있기에 200, 400, 500번대 상태 코드 중에서도 빈도가 높은 것만 알아보자

 

- 200번대 상태 코드

  > 200 : 요청을 정상적으로 처리하였음

  > 201 : POST 요청을 정상적으로 처리하였음

  > 204 : 요청을 처리했지만 전달할 데이터가 없음

 

- 400번대 상태 코드

  > 400 : 클라이언트측의 문제로 요청을 처리하지 못했음

  주로 API에 필요한 파라미터를 전달하지 않았을 때 발생 시키는 상태코드

  > 401 : 인증(로그인 등)이 필요한 기능인데 인증을 하지 않고 접근했음

  > 403 : 인증(로그인 등)은 했지만 접근 권한이 없는 사용자임

  > 404 : URL을 잘못 입력해 해당 위치에 리소스가 없음

  > 405 : 해당 요청 방법(Method)은 API가 받을 수 없음

 

- 500번대 상태 코드

  > 500. 502, 503 : 서버측의 문제로 요청을 처리하지 못했음

---

요즘은 RESTfulAPI 보다 DDD, MSA, GraphQL로 많이 전환되는 추세임

그래도 RESTfulAPI는 없어질 수 없고 지금도 그리고 앞으로도 굉장히 중요한 개발 방식 중 하나이므로 잘 알아둬야함

 

RESTfulAPI에 대해서 끝장을 보고 싶다 라면 아래 책을 보면 끝장을 볼 수 있을 것

HTTP 완벽 가이드 - YES24

 

참고 : https://aws.amazon.com/ko/what-is/restful-api/, https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80, https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html,  https://meetup.nhncloud.com/posts/92