31~35일차 스터디

1. OSI 7레이어
2.  HTTP 메소드 및 멱등성과 안정성
3. 국내 데이터 API 불러오기

 

 

1. OSI 7레이어

 

 

 

 

계층을 나눈 이유는 통신이 일어나는 과정이 단계별로 파악할 수 있기 때문이다.

흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽고, 7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들이지 않고도 이상이 생긴 단계만 고칠 수 있다.

 

1) 물리(Physical)

→ 리피터, 케이블, 허브 등

데이터 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간. 즉, 데이터를 전송하는 역할만 진행한다.

 

2) 데이터 링크(Data Link)

→ 브릿지, 스위치 등

물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할.

Mac 주소를 통해 통신한다. 프레임에 Mac 주소를 부여하고 에러검출, 재전송, 흐름제어를 진행한다.

 

3) 네트워크(Network)

→ 라우터, IP

데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당한다.

라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달해준다.

라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행한다.

 

4) 전송(Transport)

→ TCP, UDP

TCP와 UDP 프로토콜을 통해 통신을 활성화한다. 포트를 열어두고, 프로그램들이 전송을 할 수 있도록 제공해준다.

• TCP : 신뢰성, 연결지향적
• UDP : 비신뢰성, 비연결성, 실시간

5) 세션(Session)

→ API, Socket

데이터가 통신하기 위한 논리적 연결을 담당한다. TCP/IP 세션을 만들고 없애는 책임을 지니고 있다.

 

6) 표현(Presentation)

→ JPEG, MPEG 등

데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당한다.

파일 인코딩, 명령어를 포장, 압축, 암호화한다.

 

7) 응용(Application)

→ HTTP, FTP, DNS 등

최종 목적지로, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.

사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스를 제공한다.

 

https://gyoogle.dev/blog/computer-science/network/OSI%207%EA%B3%84%EC%B8%B5.html

OSI 7 계층 | 👨🏻‍💻 Tech Interview

 

https://onecoin-life.com/19

[네트워크] OSI 7Layer / 7계층 개념 및 역할, 구조까지 한번에 알아보기

 

 

---

2. HTTP 메소드

클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식. 

클라이언트가 웹 서버에게 요청의 목적이나 종류를 알리는 수단이라고도 한다.

총 9가지의 메소드가 있지만, 5가지가 흔하게 쓰인다. 

GET 리소스 정보 조회. 
POST 등록. 서버에 입력 데이터를 전송. 리소스의 위치를 지정하지 않았을 때 리소스 생성.
PUT 리소스의 위치를 명확히 알고서 요청. 이미 있는 데이터를 대체, 혹은 생성함.
PATCH 리소스의 부분 수정. PUT과 마찬가지로 리소스의 위치를 클라이언트가 알고 있을 때 사용.
DELETE 리소스 삭제. 요청 URL로 지정한 리소스를 삭제할 것을 요청.

HEAD GET과 비슷한데, 서버에서 상태 코드와 헤더만 반환
OPTIONS 통신 가능 옵션을 설명(CORS에 자주 사용)
CONNECT 요청된 리소스와 양방향 통신을 시작, 터널을 열기 위해 사용.
TRACE 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌. 디버깅용으로 사용.

 

 

🎈메소드의 멱등성?

우선 멱등성에 대해 살펴보자.

멱등성이란, 수학이나 연산에서 어떤 대상에게 같은 연산을 여러 번 적용해도 결과가 달라지지 않는 성질을 일컫는다. 

그렇다면 HTTP 메서드에서 멱등성이란 무엇을 의미할까?

 

특정 메서드의 요청을 여러 번 하더라도 한번 요청했을 때와 결과가 같을 시 해당 HTTP 메서드는 멱등성을 가진다고 한다. 주의할 점은 리소스에 수정이 발생한다고 해도 한번 실행한 결과가 여러 번 실행한 결과와 같다면 멱등성을 가진다고 할 수 있다는 부분이다. 리소스가 수정되지 않는 상태는 아래서 설명할 안전성이다. 또한 '서버의 상태'에도 주목해야 한다. 서버의 상태가 동일하면 응답상태 코드가 다르다고 해도 멱등성을 가진다(이게 뭔 소리임?) 

 

💢대체 이놈의 멱등성은 왜 알아야 하는 것인가?

간단히 설명하자면, 요청의 재시도 때문이다. 가령 네트워크 상에 어떠한 요청을 보냈는데, 여러 이유(지연, 패킷 손실 등) 탓에 요청이 실패했다고 가정해보자. 만약 HTTP 요청이 멱등성을 갖는다면 실패한 경우 바로 재시도 요청을 해도 문제가 없다. 그러나 HTTP 요청이 멱등적이지 않았다면? 리소스가 이미 처리되었는데 중복 요청을 보내는 일이 발생할 수 있다. 예를 들어 이미 결제된 요청인데, 중간에 연결이 끊겨서 다시 결제 요청을 보낸다면 여러번 결제가 되는 심각한 문제가 생길 수 있다.

반면 안정성과 멱등성을 둘다 가지는 GET 메소드는, 요청을 하고 응답을 못 받았을 경우 자동으로 한번 더 보내더라도 안전하다고 볼 수 있다. 따라서 클라이언트는 멱등성을 고려하여 재시도 요청을 해야 하는 것이다.

 

멱등성을 보장해야 하는 메소드- GET, PUT, DELETE, HEAD, OPTIONS, TRACE

멱등성을 보장하지 않는 메소드- POST, PATCH, CONNECT

 

굵은 글씨로 표현한 자주 쓰이는 5가지 메소드,

그중 멱등성을 보장하지 않는 메소드들에 대해서 알아보기로 하자.

 

POST는 리소스를 새로 생성하기에 멱등하지 않다. 여러번 수행할수록, 매번 새로운 리소스가 생성되면서 연산의 수행 결과 또한 달라진다.

 

PATCH는 리소스를 부분적으로 변경할 때 사용한다. 이 메소드는 전체를 다 변경해주거나 데이터를 넣는 PUT과 달리 멱등하지 않을 수 있다.

주의할 점은 멱등하게 설계할 수도 있지만, 항상 멱등성을 보장하지는 않는다는 것이다.

아래와 같은 예시를 보자.

{
  "operation": "add",
  "age": 10
}

위 요청을 PATCH 메소드로 보낼 때, 서버에서 operation add의 의미를 알고 있다면 메소드는 한번 호출할 때마다, age에 10씩 더할 것이다. 즉 PATCH는 아래와 같은 두 가지 요청을 한다.

1. 기존에 있던 값과 상관 없이 이 데이터를 넣어 변경해 줘라.

2. 기존에 있던 값에 대해 이런 연산을 진행해서 이 데이터를 통해 데이터를 변경해 줘라.

이처럼 PATCH 메소드는 구현 방법에 따라 멱등성이 보장될 수도 있고, 혹은 보장되지 않을 수도 있다.

 

 

그렇다면 멱등성을 왜 갖는지 의문인 메소드들은 어떨까?(내가 헷갈렸다...)

PUT은 요청에 담긴 리소스로 데이터를 넣어주거나 기존 리소스를 대체해준다. PATCH와 달리 일부분만 수정이 아니라 해당 URI에 있는 모든 리소스를 대체해주는 것이다. 따라서 여러번 연속으로 수행해도 요청에 담긴 리소스가 변하지 않는 이상 연산의 결과는 동일하다. 따라서 멱등성을 가진다.

DELETE는 삭제하는 메소드라서 멱등성을 가진다. 한번 삭제하고, 두번 삭제하고 100번 삭제해도 한번 '삭제된 상태'라는 결과는 동일하다. 그러니 REST API를 따지면 DELETE 메서드를 사용해서 "목록의 마지막 항목을 제거하기" 기능을 구현해서는 안 된다.

 

물론 서버는 멱등성을 보장하지 않는다. 따라서 일부 애플리케이션은 잘못된 구현으로 멱등성 제약을 어길 수도 있다는 점을 늘 잊지 말고 주의해야 할 것이다. 

 

🎈 메소드의 안전성?

우선, 안정성은 멱등성과 다르다는 사실을 명시한다.

메소드에서 안전성이란 HTTP 메서드가 서버의 상태를 바꾸지 않는 것을 의미한다. GET, OPTIONS, HEAD처럼 수정 및 삭제를 하지 않으며 읽기 전용인 메서드들은 안전하다고 말할 수 있다. 메서드 호출로 인해 서버의 상태가 직접적으로 변화가 되지 않는다면, 무조건 안전한 메서드이다. 

반면 PUT과 DELETE 메서드는 위에 설명했듯 멱등성을 갖는다. PUT은 리소스를 수정하고 DELETE는 리소스를 제거하므로 멱등하지만 안전한 메서드라고는 할 수 없다. 

 

 

https://doqtqu.tistory.com/282 

[RESTful] API 설계 PUT vs PATCH

 

https://roxy.iro.ooo/infra/protocol/http/http-idempotent

HTTP 메서드의 속성, 멱등(Idempotent)이란? | ROXY

---

3. 국내 데이터 API 불러오기

3.1 카카오 개발자 사이트

카카오 개발자 사이트에서 API키를 발급 받고 사용할 수 있다.

푸시 알림, 카카오페이, 검색, 번역, 카카오 맵이나 로그인 등을 제공한다. 

https://developers.kakao.com/

Kakao Developers

 

3.2 네이버 개발자 사이트

https://developers.naver.com/products/intro/plan/plan.md

네이버 오픈 API 목록 - INTRO

 

3.3 국내 공공 데이터 포털 

국내 공공데이터 포털에서도 공공데이터 API를 제공받을 수 있다. 공공 데이터 API는, 나라에서 보유한 데이터 프로그램을 허가 받아 각자의 인증키로 사용할 수 있다. 파일을 신청하면, 개인에게 고유한 인증키를 발급해준다. 간혹 신청하고 나서 허가까지 몇 시간이 걸릴 수도 있으니 사용하고 싶다면 미리 신청을 하도록 하자.

https://www.data.go.kr/

공공데이터 포털

원하는 자료를 다음과 같이 얻을 수 있다. JSON파일이 대부분이지만 간혹 XML도 있으니 둘다 다룰 줄 알아야 할 것.

이처럼 필요한 키를 미리 알려준다. '필' 이라고 적혀있는 키들은 모두 요청할 때 넣어줘야 한다.