목차

1. 주제 선정 이유

2. API란 무엇인가?

3. REST API란 무엇인가?

• REST의 개념
• REST의 4가지 원칙
• REST API의 개념
• REST API를 사용하는 이유
• HTTP API의 개념

4. HTTP 메서드 정리

• GET
• POST
• PUT
• PATCH
• DELETE

5. HTTP 메서드 속성

• 안전
• 멱등
• 캐시가능

6. 요약 정리 및 면접형 QnA

1. 주제 선정 이유

지난 IT용어 정리에서 API에 대한 설명을 했으나, 가장 중요한 REST API에 대한 설명을 간략하게 했다고 생각해서 해당 주제에 대해 자세히 설명하고자 선정했다. 프론트 엔드뿐만 아니라 IT업계에서 가장 많이 사용하는 API 방식이기에 이에 대한 정확한 개념은 반드시 숙지해야 할 것이다.

2. API란 무엇인가? === 메뉴판

• Application Programming Interface의 앞자리를 조합하여 만든 용어로, 응용 프로그램을 프로그래밍하기 위해 서로 데이터를 주고 받는 상호작용의 방법이라고 정의할 수 있다.
• 데이터를 요청하는 클라이언트(프론트엔드)에게 서버(백엔드)가 데이터를 제공해주며, 이러한 상호작용을 가능하게 해주는 것이 API이다.

3. REST API란 무엇인가?

3-1. REST의 개념

• REpresentational State Transfer의 약자로, 웹 서비스를 위한 아키텍처 스타일이다.
• HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
• HTTP 프로토콜에 따르는 모든 플렛폼에서 사용이 가능

* CRUD란

Create(생성), Read(조회), Update(갱신), Delete(삭제)의 약자로, 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리기능들을 묶어서 일컫는 말이다.


데이터 베이스에서의 기초적인 4가지 쿼리 형식
Create - 생성 - INSERT
Read - 조회 - SELECT
Update - 갱신 - UPDATE
Delete - 삭제 - DELETE


클라이언트 <-> 서버간의 HTTP프로토콜을 이용한 REST API 용어
Create - 생성 - POST
Read - 조회 - GET
Update - 갱신 - PUT, PATCH
Delete - 삭제 - DELETE

3-2. REST의 4가지 원칙

• 균일한 인터페이스 : URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스(HTTP 표준 프로토콜기준)로 수행
• 무상태 : 서버가 이전의 모든 요청들을 독립적으로 처리하여 응답하는 것을 의미
• 계층화 시스템 : REST Server가 다중계층으로 이루어 질 수 있다는 것을 의미(API Server, 보안, 로드벨런싱, 암호화, 사용자 인증)
• 캐시 가능성 : 보다 효율적인 요청 처리를 위해 캐시 사용을 하며, 이를 통해 REST Server의 트랜젝션이 발생하지 않아 전체 응답시간, 성능, 서버의 자원 이용률을 줄일 수 있음

3-3. REST API의 개념

• 어원적으로 분석하면 '대표적인 상태 전달자'로 API 방식 중 가장 많이 그리고 표준적으로 사용되는 방법론이다.
• 아키텍처는 시스템을 구성하는 구성요소들의 조합과 그들 간의 상호작용 방식을 설계하는 것을 의미하며, REST API에서 언급하는 웹 서비스를 위한 아키텍처는 클라이언트-서버 아키텍처를 의미한다.
• 클라이언트-서버 아키텍츠는 클라이언트와 서버가 각자의 역할을 분배하여 시스템을 구성한다. 클라이언트는 사용자 인터페이스나 요청을 처리하고, 서버는 그에 필요한 데이터를 전달 및 처리를 하는 역할을 수행한다.
• 즉, REST API는 웹 서비스를 위한 클라이언트와 서버의 시스템(아키텍처)적 스타일이라 정리 할 수 있다.
• REST API는 HTTP 프로토콜을 기반으로 동작한다.
• RESTful == REST API를 사용한 웹 서비스

3-4. REST API를 사용하는 이유

• 자원(Resource) 중심적: 리소스(데이터)를 중심으로 API를 설계한다. 각 리소스는 고유한 식별자(URI)를 가지기 때문에 가독성이 좋아 수정이나 변경이 용이하다.
• 표준화된 인터페이스: REST API는 일반적으로 HTTP 메서드(GET, POST, PUT, DELETE)와 HTTP 상태 코드(200 OK, 404 Not Found 등)를 사용하여 일관된 인터페이스를 제공한다. 이는 개발자가 API를 이해하고 사용하기 쉽도록 도와준다.
• 사내 시스템들도 REST 기반으로 시스템을 분산해서 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 함
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악
• REST는 HTTP 표준을 기반으로 구현하기에, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있음(java,javascript)

* HTTP는 무엇인가?

• HyperText Transfer Protocol의 약자로, 인터넷에서 웹페이지를 전송하기 위해 사용하는 프로토콜(규칙)을 의미한다.
• HTTP는 클라이언트가 데이터를 '요청'하고 서버가 이에 '응답'하여 데이터를 주고받는 형태로 이루어져 있다.
• REST API는 HTTP 프로토콜을 기반으로 동작하기에, 각종 HTTP 메서드를 활용하여 사용자에게 표준화된 인터페이스를 제공한다.

4. HTTP 메서드 정리

• GET : 요청받은 URI의 정보를 검색하여 응답한다. 주로 사용자가 클릭하는 대부분의 버튼들이 GET 메서드를 사용한다고 생각해도 무방하다.
  ex). GET /index.html HTTP/1.1
• POST : 요청된 자원을 생성(create)한다. 즉, 서버에 새로운 리소스를 생성하거나, 서버에 데이터를 제출하여 처리하고자 할 때 사용한다. 주로 게시물을 작성하거나, 주문 정보를 생성하거나, 새로운 파일을 업로드 하는 등, 새로운 자원을 생성할 때 사용한다.
  ex). POST / request-uri/ HTTP/1.1
• PUT : 요청된 자원 전체를 수정(update)한다. 기존의 URI에 내용을 수정하는 것이기에 새로운 URI를 생성하는 POST와는 차이를 두어야 한다. 주로 리소스를 업데이트할때 PUT 메서드를 사용한다고 이해하면 된다.
  ex). PUT / request-uri/ HTTP/1.1
• PATCH : 요청된 자원을 수정(update)한다. 다만, 자원 전체를 수정하는 PUT메서드와는 달리, PATCH메서드의 경우 해당자원의 일부만을 교체한다는 차이점이 있다.
  ex). PATCH / request-uri/ HTTP/1.1
• DELETE : 요청된 자원을 삭제할 것을 요청한다. 하지만 안정성의 문제로 대부분의 서버에서는 비활성화 되어있으며, 주로 PATCH를 통해 수정한다고 한다.
  ex). DELETE / request-uri/ HTTP/1.1

4-1. POST와 PUT의 차이는 무엇인가?

• POST 메서드는 INSERT이며 PUT 메서드는 UPDATE이다.
• POST메서드의 경우, 멱등하지 않아 동일한 자원을 여러번 POST하면 서버자원에 변화가 생긴다.
• PUT메서드의 경우, 멱등하여 동일한 자원을 여러번 PUT하면 서버자원이 변화하지 않고 동일한 리소스로 응답한다.
• 즉, POST메서드는 새로운 자원을 생성하기에 여러번 요청하면 서버 리소스에 변화가 생기지만, PUT의 경우, 생성이 아닌 수정을 하며, 여러번 요청해도 서버 리소스에 변화가 없다.

4-2. PUT과 PATCH의 차이는 무엇인가?

• PUT은 해당 자원의 전체를 교체하지만, PATCH는 일부만 변경한다.
• PUT은 덮어쓰기, PATCH는 업데이트.

5. HTTP 메서드 속성

1. 안전(Safe Methods)

• 호출을 해도 리소스가 변경하지 않는다.(GET만 계속 호출해도 안전, 나머지는 불안전)

2. 멱등(Idempotent Methods)

• 몇번 호출해도 결과가 똑같은가? (POST만 멱등이 아니다, 호출 결과가 늘 새롭기 때문)
• 활용 -> 자동 복구 메커니즘 (delete 같은 경우, 서버 이슈로 정상 응답을 주지 못했다면, 멱등하기 때문에 다시해도 괜찮음)
• 멱등은 외부요인으로 중간에 리소스가 변경되는 것까진 고려하지 않는다.

3. 캐시가능(Cacheable Methods)

• *캐시 : 기록
• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• 스팩상 GET,HEAD,POST,PATCH는 캐시 가능 -> 하지만 실제로는 GET,HEAD 정도만 캐시로 사용

6. 요약 정리 및 면접형 QnA

6-1. Q. REST API가 무엇인가요?

• REST API는 HTTP 프로토콜을 기반으로 동작하는, 웹 서비스를 위한 클라이언트와 서버의 시스템(아키텍처)적 스타일입니다.
• REST API가 각광받는 이유는 각 리소스는 고유한 식별자(URI)를 가지기 때문에 가독성이 좋아 수정이나 변경이 용이하고, 일관된 HTTP 프로토콜을 따르기에 개발자로 하여금 친숙하고 편리하기에 자주 사용됩니다.

6-2. Q. POST와 PUT의 차이는 무엇인가?

• POST 메서드는 INSERT이며 PUT 메서드는 UPDATE입니다.
• POST메서드의 경우, 멱등하지 않아 동일한 자원을 여러번 POST하면 서버자원에 변화가 생깁니다.
• PUT메서드의 경우, 멱등하여 동일한 자원을 여러번 PUT하면 서버자원이 변화하지 않고 동일한 리소스로 응답합니다.
• 즉, POST메서드는 새로운 자원을 생성하기에 여러번 요청하면 서버 리소스에 변화가 생기지만, PUT의 경우, 생성이 아닌 수정을 하며, 여러번 요청해도 서버 리소스에 변화가 없습니다.

6-3. Q. PUT과 PATCH의 차이는 무엇인가?

• PUT은 해당 자원의 전체를 교체하지만, PATCH는 일부만 변경합니다.

6-4. Q. 멱등(Idempotent)은 무엇인가?

• 동일한 작업을 여러 번 실행하더라도 결과가 동일하게 유지되는 성질을 의미합니다.
• 즉, 동일한 요청을 여러 번 실행하더라도 처음 요청과 같은 상태와 결과를 얻을 수 있다는 것을 의미합니다.
• 이는 요청의 반복 실행이나 중복 전송이 발생해도 시스템의 상태가 변하지 않는 것을 의미합니다.