[스터디] RESTful API, HTTP Protocol (2회차)

😁 배운 내용

RESTful API의 개념과 등장한 이유를 조금 이해할 수 있었습니다.
지금까지 개발 공부를 하면서 가장 효과적이었던 방법은 왜 해당 기술이 등장했는지 이해하고, 그 기술을 다시금 바라봤을 때 조금 더 친숙해지고 이해할 수 있었습니다.

사실 처음 RESTful API에 대해서 찾아봤을 때는 꽤 막막했습니다. 설명하는 글들 대부분이 추상적으로 다가왔고, RESTful한것과 not RESTful 한 것의 차이를 구분하기 어려웠습니다. 많은 아티클을 읽고, 여러 정보를 찾아보면서 내가 이해한 언어로 하나씩 풀어가면서 조금씩 이해할 수 있었던 것 같습니다. 아직 완벽하다고는 할 수 없지만, 해당 개념을 이해하는데 좋은 포문을 연 것 같습니다.

HTTP 통신을 다시 찾아보면서 새로운 개념을 얻는 것도 중요하지만, 이미 알고 있다고 생각하는 것들을 다시 한번 알아보고 공부해보면 생각보다 놓치는 것이 많은 것 같습니다. 공부는 끝이 없는 것 같습니다 ㅎㅎ ㅠ

✏️ 미션 제출

📌 RESTful API에 관해 설명해주세요.

✔︎ RESTful API란?

RESTful API(REST API)는 REST(Representational State Transfer) 아키텍처를 따르는 웹 서비스 API이다. 해당 아키텍처는 네트워크상에서 자원을 식별하고, 해당 자원에 대한 행위를 정의하는 HTTP 메소드를 사용하여 상호작용을 하는 것을 기본 원칙으로 둔다.

결국 자원을 특정 이름으로 구분하여 해당 자원의 정보를 주고받는 모든 것을 의미한다.
REST 형식을 따르는 API 개발을 REST API 혹은 RESTful API라고 한다.

 

✔︎ API란?

Application Programming Interface의 약자로 다른 애플리케이션과 상호작용하기 위한 인터페이스를 의미한다. 클라이언트가 서버와 데이터를 주고받을 수 있는 규칙, 규격을 제공한다.

API를 이용하면 내부 구현 방식을 알지 못하는 제품 또는 서비스와 통신할 수 있으며 결국 클라이언트와 서버를 이어주는 일종의 통로 역할을 한다고 할 수 있다.

 

✔︎ REST란?

REST는 표준, 프로토콜의 개념이 아니라 일련의 아키텍처 제약조건을 말한다.

RESTful한 API를 만들기 위해서는 다음과 같은 특징을 따라야 한다.

1. Server-Client 구조
   클라이언트/서버 구조를 따라야 한다. 클라이언트의 HTTP 요청에 따라 서버는 HTTP 프로토콜을 통해 응답 정보를 전송한다.
2. Stateless(무상태)
   Client-Server 간 상태를 저장하고 관리하지 않는다. 각 요청은 서로 독립적이어야 하며, 이전 요청에 대한 정보는 서버에서 유지하지 않는다.
3. Cacheable(캐시 가능성)
   응답에 대해 캐시가 가능, 불가능 여부를 암시적 혹은 명시적으로 지정한다. 응답이 캐시가 가능하다면 이후 동등한 요청에 캐시한 데이터를 재사용할 수 있다.
4. Uniform Interface(통일된 인터페이스)
   REST는 구성 요소 간 균일한 인터페이스에 중점을 둔다. 또한 일반화를 통해 실제 통신에 이용되는 모듈(컴포넌트)에 적용해 전체 시스템의 구조가 단순화되고 클라이언트와 서버의 통신 가시성이 증가한다. 하지만 통일된 인터페이스는 각 애플리케이션의 요구사항에 맞추지 않고 표준화시킨 형태이므로 효율성이 저하된다는 단점이 존재한다.

즉, HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능하며 특정 언어, 기술에 종속되지 않아야 한다.

• Uniform Interface의 제약조건
  1. Identification of resources
     모든 요청은 리소스를 식별해야 한다. 어떤 자원을 제어하려는지 알아야 하고 자원 제어를 위해 자원의 위치, 종류까지 알아야 한다.
  2. manipulation of resources through representational
     서버는 리소스를 자세히 설명하는 메타데이터를 전송해 클라이언트가 원하는 리소스를 수정, 삭제하기에 충분한 정보를 제공한다.
  3. self-descriptive
     메시지는 자신을 스스로 설명해야 한다. 데이터 처리를 위한 정보를 얻기 위해 데이터 원본을 읽어야 한다면 이 조건을 만족하지 못한다.
  4. HATEOAS
     Hypermedia As The Engine Of Application State로 애플리케이션의 상태는 하이퍼링크를 통해 전이되어야 한다. 특정 행위에 대한 응답에 클라이언트가 다음 행동으로 요청할 부분들을 Hypermedia를 통해서 넣는다.
  5. Layerd System(계층 시스템)
     각 컴포넌트를 상호작용하는 바로 앞의 계층 너머를 볼 수 없도록 제한하고, 클라이언트는 클라이언트와 서버 사이 다른 승인된 중개자에게 연결할 수 있다.

6. Code-On-Demand(선택사항)
   클라이언트는 서버에서 제공하는 실행 가능한 코드를 수신하여 실행할 수 있어야 하지만, 선택적이다.

 

✔︎ RESTful API의 구성

• 구성요소: 자원(Resource) - URI, 행위(Verb) - HttpMethod, 표현(Representation)

1. 자원(Resource) - URI
   API에서 제공하는 모든 것은 자원으로 표현한다. 각 자원은 고유한 ID를 가지며 URI를 통해 식별된다.
2. 행위(Verb) - HttpMethod
   자원에 대한 행위는 HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용해 정의함
3. 표현(Representation)
   클라이언트와 서버 간에 자원에 대한 정보를 주고받을 때는 JSON, XML, HTML 등의 형식으로 표현된다. 현재는 API 하면 JSON을 주고받는 통신을 말한다.

 

✔︎ RESTful API의 간단한 예시 "users"

users라는 자원에 대한 CRUD 동작을 수행하는 API는 URI + HTTP Method를 통해 정의할 수 있다.

POST /users (사용자 생성: C)
GET /users (사용자 목록 조회: R)
GET /users/{user_id} (특정 사용자 조회: R)
PUT /users/{user_id} (사용자 정보 수정: U)
DELETE /users/{user_id} (사용자 삭제 D)

• 규칙
  • (/)는 계층 관계를 나타낼 때 사용
  • URI 마지막 문자로 (/)포함 X
  • 하이픈(-)은 URI 가독성을 높이는 데 사용(밑줄은 사용 X)
  • URI 경로에는 소문자가 적합
  • 파일 확장자는 URI에 포함하지 않는다.
  • 명사를 사용한다. (동사는 행위의 의미를 가짐, 행위는 Http Method로 표현)
  • 컨트롤 자원(데이터를 다루기 위한 로직 수행)을 사용하는 URI는 동사를 허용한다.
    ex) POST /login

❗️ 참고
Architectural Styles and
the Design of Network-based Software Architectures - Roy Thomas Fielding
RESTful API란 무엇인가요 - AWS
What is a REST API? - Red Hat
REST API Tutorial - restfulapi
네트워크 📚 REST 이해하기 - Betterfuture4 velog
RESTful API 이란 - levi velog

📌 HTTP 통신에 관해서 설명해주세요

✔︎ HTTP Protocol

HTTP는 HyperText Transfer Protocol의 약자이며 분산 하이퍼미디어 환경에서 빠르고 간편하게 데이터를 전송하는 프로토콜이다.

HTTP는 TCP 프로토콜의 80번 포트를 사용하도록 정의된다. HTTP 서버는 80번 포트에서 대기하고, 클라이언트는 TCP를 사용해 연결을 설정한다.

HTTP 서버로부터 웹 정보를 얻으려면 http://xxx.com과 같이 URL 주소에 HTTP 프로토콜의 사용에 대한 명시를 해야 한다. HTTP 프로토콜은 HTTP 명령에 해당하는 HTTP Method를 이용해 클라이언트가 서버에 요청을 전송하고, 반대로 서버에서 클라이언트로 문서 정보를 회신한다.

HTTP 통신은 현재 인터넷에서 가장 많이 사용되는 프로토콜이다.

• 비상태 연결
  TCP 연결이 설정된 후 요청 및 응답이 진행되고 이어서 TCP 연결이 해제되므로 둘 사이에는 연결 상태에 대한 정보가 존재하지 않는다. 따라서 Stateless Protocol이다.
• 요청 메시지
  클라이언트 to 서버로 보내는 Request Message는 Request Line, Header, Body로 구성된다. Header와 Body 사이에는 공백 한 줄이 존재한다.
• 응답 메시지
  서버는 클라이언트로부터 요청 메시지를 수신하고 처리한 후 그 결과를 응답 메시지 형식으로 회신한다.
  요청 메시지와 형식이 거의 비슷하지만 Request Line 대신 Status Line이라는 용어를 사용한다.
• Request Line과 Status Line
  Request Line은 요청 메서드 URL HTTP 버전으로 구성된다. 요청 메서드는 HTTP Method가 된다.
  Status Line은 HTTP 버전 상태코드, 상태이름으로 구성된다.

Hypermedia
하이퍼텍스트의 커다란 집합체, 하이퍼텍스트는 일반적인 텍스트와 큰 차이가 없지만 하이퍼링크라는 다른 문서로의 연결고리를 가지는 특징이 있다. 즉 하이퍼텍스트는 특정 문서에서 특정 단어를 클릭하게 되면 스크린 위에 새로운 문서를 나타나게 하는 텍스트를 말한다.
따라서 하이퍼미디어는 하이퍼텍스트 + 멀티미디어의 조합이다. 텍스트로 하이퍼링크를 가지며 단순 텍스트뿐만 아니라 음성, 영상 등의 멀티미디어데이터가 합쳐져 있다.

TCP Protocol
전송 계층의 프로토콜로 IP 프로토콜 위에서 연결형 서비스를 지원한다. 인터넷 환경에서 기본적으로 사용하며 연결형 서비스 제공, 전이중 방식의 양방향 가상 회선 제공, 신뢰성 있는 데이터 전송을 보장한다.

 

✔︎ HTTP 통신의 동작 과정

1. 클라이언트가 서버에게 요청을 보냄(Request)
   요청에는 요청하는 리소스를 식별하는 URI와 HTTP 메소드가 포함된다.
2. GET /index.php HTTP/1.1 -> Request Line Host: uu.ac.kr -> Request Header -> 공백 라인
3. 서버는 요청에 대한 응답(Response)을 생성한다.
   응답은 상태 코드와 함께 클라이언트에게 전송된다. 상태코드는 요청에 대한 결과 정보를 나타냅니다.
4. HTTP/1.1 200 OK -> Status Line Content-Type: text/html -> Response Header Content-Length: 1000 -> 공백 라인 -> Body ...

❗️ 참고
쉽게 배우는 데이터 통신과 컴퓨터 네트워크 3판 - 박기현
Chat GPT

📌 HTTP 메소드 GET과 POST의 차이

✔︎ GET의 특징

HTTP GET 메서드는 지정된 리소스의 표현을 요청하고 GET을 사용한 요청은 데이터를 요청할 때만 사용해야 한다.

위에서 멱등성은 동일한 요청을 100번 해도 응답(결과)이 달라지지 않음을 말한다. GET은 단순 데이터 요청이므로 멱등성을 충족한다.

 

✔︎ POST의 특징

HTTP POST 메서드는 데이터를 서버로 전송한다. 요청 본문의 유형은 Content-Type 헤더로 표시된다.

POST는 상품 주문과 같은 주문할 상품 데이터를 서버로 전송한다. 만약 상품이 품절되는 경우 아닌 경우를 생각해봤을 때 서버로부터의 응답(결과)이 달라지므로 멱등성을 충족하지 못한다.

또한 데이터를 전송하기 위해 Request에 Message Body가 존재한다.

 

✔︎ GET과 POST의 차이

GET은 특정 리소스의 표현을 요청하는 단순 데이터 요청 시에 사용되며 HTTP Request의 Message Body를 가지고 있지 않다. 단순 데이터 요청이므로 몇 번을 요청하든 동일한 결과를 보여주므로 멱등성을 충족한다.

반면에 POST는 클라이언트에서 서버로 데이터를 전송할 때 사용되며 이를 위해 데이터를 담기 위한 Request Body가 존재한다. 또한 동일한 요청에 대해서 다른 서버 응답 결과가 나타날 수 있으므로 멱등성을 충족하지 못한다.

GET과 POST 모두 query string을 통해 데이터를 담을 수 있는데 GET은 HTTP Message Body가 없으므로 URL 끝에 쿼리 스트링 형태로 전송된다. 반면에 POST는 HTTP Message Body에 쿼리스트링 형식으로 포함해 전송한다.

• GET 메서드의 쿼리스트링 전송
• GET /hello?data=hi&name=test HTTP/1.1 Host: ~~
• POST 메서드의 쿼리스트링 전송
• POST /hello HTTP/1.1 Content-Type: ~~ Content-Length: ~~ data=hi&name=test

GET과 POST는 위와 같은 쿼리스트링의 다른 전송 방식 때문에 GET보다 POST 방식에서 더 많은 데이터를 전송할 수 있고, GET은 URL에 노출되므로 POST에 비해 보안에 취약하다.
(암호화를 시키지 않는다면 POST의 보안성도 그저 그렇다는 의견이 많다)

❗️ 참고
HTTP request methods - MDN web docs

📌 Postman으로 원하는 정보를 얻을 수 있는 API 호출

✔︎ 모든 post 들을 조회하기

JSONPlaceholder는 100개의 post 데이터를 가지고 있다.
전체 post에 대한 리소스는 다음과 같이 요청할 수 있다.

• 요청
• 
• 응답
• 

✔︎ 2번 post 조회하기

• 요청
• 
• 응답
• 

 

✔︎ 3번 post에 대한 comment를 조회하기

1. Path Variable 이용
   Path Variable은 자원의 위치를 특정해서 보여줘야 할 경우 사용된다.
2. 
3. Query String 이용
   Query String은 자원에 대한 정렬 혹은 필터링이 필요한 경우 사용된다.
4. 

위 두 개념은 웹에서 어디(End-Point)에 요청하는지에 대해 HTTP Method와 결합해 CRUD 프로세스를 추가적인 End-Point없이 요청을 완결지을 수 있다.

참고
When Should You Use Path Variable and Query Parameter?

 

✔︎ post 하나 등록하기

https://jsonplaceholder.typicode.com/posts/1로 요청하면 post에 전달해야 할 데이터들을 살펴볼 수 있다.

id값을 제외한 userId, title, body값을 쿼리스트링에 담아 POST 요청을 보내면 101번째 post가 등록된다.

다른 방법으로 JSON을 통해 등록할 수 있다.

📌 Postman으로 공공데이터 api 호출하기

공공데이터 포털에 회원가입을 하고 원하는 공공데이터를 신청하면 인증키를 받을 수 있다.

인증키는 일반 인증키(Encoding, Decoding) 두 종류를 받는 데 이를 이용해 공공 API를 호출할 수 있다.

위와 같이 포털에서 정해준 쿼리 파라미터를 통해 데이터를 조회할 수 있다.

따라서 Postman으로 조회하면 다음과 같은 결과를 얻을 수 있다.

🤔어려웠던 점 + 고민되는 부분

항상 해외의 공식문서, 아티클, 논문 등을 읽는 경우 일반적인 글보다 짧은 문장이어도 선택하는 단어나 어조들이 상당히 추상적이고 이해하는 데 시간이 걸립니다.
그래서 여러 자료를 찾아보고 자연스럽게 쉬운 말로 된 글들을 보려고도 합니다.

우리가 사용하는 Java, Spring은 서구권에서 만든 기술이고, 정말 좋은 자료들은 대부분 영어로 되어있기 마련입니다. 영어 공부는 필수적이지만, 해당 영어를 해석했을 때 단어들은 상당히 딱딱하고 이해하기 어렵다고 느껴지고 결국 이해하는 데 많은 시간이 걸리게 됩니다.

편법은 없다고 하지만, 새로운 개념을 접하고 공식문서나, 논문과 같이 상당히 함축적인 글들을 이해하는 시간을 줄이려면 어떻게 접근하고 공부하는 것이 좋을지 고민이 됩니다!