국비학원 38일차 : HTTP, API

HTTP

HTTP(Hypertext Transfer Protocol)는 인터넷에서 데이터를 주고받는 프로토콜 중 하나로, 웹 브라우저와 웹 서버 간의 통신에 사용됩니다.

HTTP 통신은 클라이언트가 서버에 요청(Request)을 보내고, 서버가 이에 대한 응답(Response)을 보내는 과정으로 이루어집니다. 요청과 응답은 각각 메시지(Message)라는 형태로 전송됩니다. (클라이언트와 서버는 상대적인 개념, 요청을 보내면 클라이언트 응답을 보내면 서버가 된다)

HTTP 요청 메시지에는 요청 라인(Request Line), 헤더(Header), 본문(Body)이 포함됩니다. 요청 라인에는 요청 메서드(Method), 요청 URI(Request Uniform Resource Identifier), HTTP 버전 등이 포함됩니다. 헤더는 요청 메시지의 부가 정보를 담고 있으며, 본문은 요청 메시지에 추가적인 데이터를 담고 있습니다.

HTTP 응답 메시지에도 요청 메시지와 마찬가지로 응답 라인(Status Line), 헤더, 본문이 포함됩니다. 응답 라인에는 상태 코드(Status Code), 상태 메시지(Status Message), HTTP 버전 등이 포함됩니다. 헤더는 응답 메시지의 부가 정보를 담고 있으며, 본문은 응답 메시지에 대한 실제 데이터를 담고 있습니다.

HTTP는 기본적으로 비상태(Stateless) 프로토콜이므로, 이전에 수행한 요청에 대한 정보를 저장하지 않습니다. 따라서 클라이언트는 매번 새로운 요청을 보내야 하며, 서버도 매번 새로운 요청에 대한 응답을 보내야 합니다.

많은 웹 애플리케이션에서는 쿠키(Cookie)나 세션(Session) 등의 기술을 사용하여 상태 정보를 유지하고, 보안을 강화하는 등의 추가적인 기능을 제공합니다.

프록시

프록시(Proxy)란 대리인이라는 뜻으로, 인터넷 사용자가 웹 사이트나 다른 인터넷 서버에 직접 접속하지 않고, 대신 프록시 서버를 통해 접속하는 방식을 말합니다.

프록시 서버는 인터넷 사용자가 요청하는 웹 페이지나 파일 등을 대신 가져오고, 해당 정보를 사용자에게 전달합니다. 이렇게 함으로써 사용자의 실제 IP 주소와 위치를 숨길 수 있습니다. 또한, 프록시를 통해 인터넷 사용자의 웹 접근 제어나, 캐시(Cache)를 통한 더 빠른 웹 페이지 로딩 등의 기능도 제공할 수 있습니다.

프록시는 주로 보안이나 네트워크 성능을 향상시키기 위해 사용됩니다. 예를 들어, 기업에서는 내부 네트워크와 외부 네트워크 간의 보안을 유지하기 위해, 내부 네트워크에서 외부 인터넷에 접속할 때 프록시 서버를 통해 접속하도록 설정하는 경우가 많습니다. 이러한 프록시 서버를 사용하면, 기업의 내부 네트워크에서 외부 인터넷으로 직접 접근하는 것보다 보안성이 높아지며, 인터넷 대역폭을 더 효율적으로 사용할 수 있습니다.

또한, 인터넷에서 프록시를 사용하는 경우, 프록시 서버의 위치를 변경하거나, 인터넷 사용자의 IP 주소를 숨기는 등의 기능으로 인터넷 사용의 보안성을 높이고, 사용자의 개인 정보를 보호할 수 있습니다.

• 캐싱 (캐시는 공개 또는 비공개가 될 수 있다 (예: 브라우저 캐시)) : 클라이언트의 기록이 남는것

• 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)

• 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용) : 부하를 분산시켜준다

• 인증 (다양한 리소스에 대한 접근 제어)

• 로깅 (이력 정보를 저장) : 서버의 기록이 남는것. 서버에서 관리자가 누가들어오고 나갔는지를학인하는 용도로 사용한다.

HTTP 통신

사용자가 HTTP 프로토콜을 이용하여 요청을 보낼 때, 일반적으로 다음과 같은 순서로 웹 서버와 WAS의 흐름이 이루어집니다.

1. 사용자가 웹 브라우저를 통해 HTTP 요청을 보냅니다.
2. HTTP 요청은 웹 서버로 전송됩니다.
3. 웹 서버는 요청에 해당하는 정적인 파일(html, css, js 등)이나 동적인 데이터를 생성하는데 필요한 정보를 찾기 위해 자신의 파일 시스템이나 캐시 등을 확인합니다.
4. 만약 요청에 대한 처리를 WAS에게 요청해야 하는 경우, 웹 서버는 해당 요청을 WAS에게 전달합니다.
5. WAS는 해당 요청을 처리하기 위해 필요한 데이터베이스나 다른 서비스 등과 통신하며, 결과를 생성합니다.
6. WAS는 생성된 결과를 다시 웹 서버에 전달합니다.
7. 웹 서버는 받은 결과를 HTTP 응답으로 포장하여 사용자에게 전송합니다.
8. 사용자는 받은 HTTP 응답을 해석하여 웹 브라우저에 렌더링합니다.

이러한 흐름에서, 웹 서버와 WAS는 보통 다른 서버로 구성되며, 웹 서버는 정적인 파일을 처리하고 WAS는 동적인 데이터를 생성하는데 사용됩니다. 또한, WAS는 보통 웹 어플리케이션을 실행하는 서버이며, 웹 어플리케이션은 사용자가 웹 브라우저를 통해 요청한 동적인 데이터를 처리하기 위한 코드와 로직을 포함합니다.

인증 상대방이 애초에 누군지 자체를 몰라서 사용할수 없다고 하는것
인가 상대방이 누군지는 알지만, 그 사람이 이 기능을 사용할 권한이 없는것. 누군지 알고자 하는 행위가 인증, 인가는 사용할 권한이 없다는 내용

HTTP Message

Request (요청)

• HTTP Method: 요청의 종류를 나타내는 부분으로, GET, POST, PUT, PATCH, DELETE 등이 있습니다.
• URL(Path): 요청을 받을 리소스의 경로를 나타냅니다.
• HTTP Version: HTTP 프로토콜의 버전을 나타냅니다.
• Headers: 요청에 대한 부가적인 정보를 포함하는 부분입니다.

HTTP Method

• GET : GET을 사용하는 요청은 오직 데이터를 받기만 함
• POST : 데이터를 저장할때 사용
• PUT : 보내는 데이터를 전부 다 업데이트
  (데이터 전체를 바꾸는 작업이므로 지양해야한다)
• PATCH : 보내는 데이터를 통해서 일부분만 수정.

기본키는 변경시키지않고 다른 작업을하면 PATCH
기본키까지 모두 변경시키는건 PUT이라고 한다.
기본키까지 바꾸는 건 지양하는게 좋다.

• DELETE : 삭제

이전에는 다양한 메서드의 방식을 사용하지 않고 GET과 POST만을 사용했다.

각각 GET과 POST의 특징만을 이용함.
GET (데이터를 url에 담아서 이동) POST(데이터를 body에 담아서 이동)
method path
GET /getBoard
POST /creatBoard
POST /updateBoard
POST /deleteBoard 형식으로 사용했었다.
실제 작업을 url로 표현
→ 수정을 해야한다면 url을 알아내기 어렵다. '수정한다'는 단어가 굉장히 많기때문에 업데이트 작업을 위한 어떤 url을 알아내기어렵다.

POST /board
GET /board
PATCH /board
DELETE /board 실제 작업들을 이제 메서드로 표현해준다
메서드로 표현을 하면 어떤 작업을 하는지 직접적으로 지시를 해주므로
알아내기가 쉽게된다. 일관성을 유지할수 있도록 해준다.

GET과 POST의 차이점

GET 방식
GET 방식은 데이터를 URL의 쿼리 스트링(query string)에 포함시켜서 전송하는 방식입니다. 예를 들어, http://example.com/search?q=apple과 같은 URL에서 q=apple은 쿼리 스트링으로, 검색어가 "apple"인 것을 나타냅니다.

GET 방식은 데이터가 URL에 노출되기 때문에 보안에 취약합니다. 또한, URL에 포함되는 데이터의 길이에 제한이 있기 때문에 대용량 데이터 전송에는 적합하지 않습니다. 그러나, 캐싱이 가능하고 브라우저에서 URL을 북마크할 수 있는 등의 장점이 있습니다. GET 방식은 일반적으로 데이터를 조회할 때 사용됩니다.

POST 방식
POST 방식은 HTTP 요청 메시지의 바디(body)에 데이터를 담아서 전송하는 방식입니다. 데이터가 URL에 노출되지 않기 때문에 GET 방식보다는 보안적으로 안전합니다. 또한, 대용량 데이터 전송이 가능합니다.

POST 방식은 데이터를 생성하거나 수정하는 등의 작업을 처리할 때 사용됩니다. 예를 들어, 회원 가입 폼에 입력한 데이터를 서버로 전송하여 회원 가입을 처리하는 경우 POST 방식을 사용합니다.

따라서, GET 방식은 데이터를 조회하는데 사용하고, POST 방식은 데이터를 생성하거나 수정하는데 사용합니다. 또한, GET 방식은 브라우저에서 캐시를 이용하여 빠른 처리를 유도할 수 있습니다. 반면 POST 방식은 중복 제출을 막기 위해 리다이렉트를 사용하는 등 추가적인 처리가 필요할 수 있습니다.

Response (응답)

• HTTP Version: HTTP 프로토콜의 버전을 나타냅니다.
• Status Code: 요청 처리 결과에 대한 상태 코드를 나타냅니다. 상태 코드는 1XX(정보), 2XX(성공), 3XX(리다이렉션), 4XX(클라이언트 오류), 5XX(서버 오류) 등으로 구분됩니다.
• Reason Phrase: 상태 코드에 대한 설명을 나타냅니다.
• Headers: 응답에 대한 부가적인 정보를 포함하는 부분입니다.

HTTP Status

HTTP 상태 코드(HTTP status code)는 HTTP 요청에 대한 서버의 응답 결과를 나타내는 세 자리 숫자로 구성된 코드입니다. 상태 코드는 클라이언트와 서버 간의 통신에서 발생하는 여러 상황을 구분하기 위해 사용됩니다. 상태 코드는 1xx, 2xx, 3xx, 4xx, 5xx와 같은 5개의 그룹으로 나눌 수 있습니다.

• 1xx (Informational, 정보성)
  1xx 상태 코드는 클라이언트 요청에 대한 정보성 응답을 나타냅니다. 서버가 요청을 수신하였으며, 추가 작업이 필요한 경우를 나타냅니다.

• 2xx (Successful, 성공)
  2xx 상태 코드는 클라이언트 요청에 대한 성공적인 응답을 나타냅니다. 대표적으로 200 OK가 있으며, 이 외에도 201 Created, 204 No Content 등이 있습니다.

• 3xx (Redirection, 리다이렉션)
  3xx 상태 코드는 클라이언트 요청에 대한 추가 조치가 필요한 경우를 나타냅니다. 대표적으로 301 Moved Permanently, 302 Found, 304 Not Modified 등이 있습니다. 300번대 자료의 위치를 변경해주는 것. 클라이언트가 보내는 요청이 다른 리소스로 가야한다는걸 알려주게된다.
  301 : 요청한 리소스의 URI가 변경되었음
  302 : 요청한 리소스의 URI가 일시적으로 변경되었음

• 4xx (Client Error, 클라이언트 오류)
  4xx 상태 코드는 클라이언트 요청이 잘못되었거나 부적절한 경우를 나타냅니다. 대표적으로 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found 등이 있습니다.
  400 회원가입 요청을 보낼때 id password는 필수인데 이것을 보내지 않았을때
  401 인증실패 토큰이 만료되었을때
  403 사용할 권한이 없다 인증/인가에 대한 자료
  404 요청 url을 잘못적었을때 반환
  405 GET 메서드와 POST 메서드에 보드가 있을때 PATCH가 없는데
  PATCH 보드로 보낸것. 리소스는 있는데 PATCH가 없으므로 오류가뜬다
  408은 인터넷 선 확인해보면 된다
  409 작업을 하는 메서드의 경우 다른 클라이언트가 해당 리소스를 쓰고있을때 상태가 충돌되게 될때.

• 5xx (Server Error, 서버 오류)
  5xx 상태 코드는 서버에서 클라이언트 요청을 처리하는 과정에서 오류가 발생한 경우를 나타냅니다. 대표적으로 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable 등이 있습니다.
  500번대에서 대부분 차지하는게 500번
  500은 서버프로그램의 웹 어플리케이션의 문제다
  예외처리를 하지 않았을 경우의 문제. 회원가입할때 아이디 비번입력했는데 중복된 아이디가 있을때 입력이 되지 않는데, 이때 검증처리를 하지 않았을경우 예외가 발생해서 출력되게 된다. null처리 등도 포함이 된다.
  502 gateway의 문제. 애초에 서버에 도달할 수 없게되는것
  라우팅 처리를 잘못했다던가, 프로토콜을 잘못입력했다던가 하는문제
  503은 인프라가 꺼져있을때 발생하는 문제
  504 서버가 프록시나 게이트웨이의 역할을 할 때 초기 서버가 원격 서버로부터 응답을 받을 수 없음

API

API(Application Programming Interface)는 응용 프로그램(소프트웨어) 간 상호작용을 위한 인터페이스를 의미합니다. 쉽게 말해, API는 응용 프로그램에서 제공하는 서비스에 대한 규격화된 방법을 제공하는 것입니다.

API를 사용하면 다른 응용 프로그램이 해당 서비스를 활용할 수 있으며, 이를 통해 소프트웨어 개발자는 자신이 구현한 기능을 다른 응용 프로그램에서도 활용할 수 있습니다.

API는 다양한 형태로 존재하며, 대표적으로 웹 API, 라이브러리 API, 운영체제 API 등이 있습니다. 웹 API는 웹 서비스를 위한 API로, HTTP를 통해 웹 서비스를 호출하고 결과를 반환합니다.

라이브러리 API는 프로그래밍 언어에서 제공하는 함수나 클래스 등을 제어하기 위한 API입니다. 이를 통해 프로그래머는 다른 개발자가 작성한 라이브러리를 쉽게 활용할 수 있습니다.

운영체제 API는 운영체제에서 제공하는 기능을 활용하기 위한 API로, 예를 들어 Windows API는 Windows 운영체제에서 제공하는 함수를 제어하기 위한 API입니다.

API는 오픈 API(Open API)와 비공개 API(Private API)로 구분됩니다. 오픈 API는 누구나 사용할 수 있는 공개적인 API이며, 대표적으로 트위터 API, 구글 맵 API 등이 있습니다. 비공개 API는 특정 기업이나 단체 등이 사용하는 API로, 보안적인 이유로 외부에 공개되지 않습니다.

API의 동작 방식

Websocket API : JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발이다. WebSocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원한다. 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적이다.

REST API : 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API이다. 클라이언트가 서버에 요청을 데이터로 전송한다. 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환한다.

Websocket프로토콜과 http,https 프로토콜 차이

Websocket API는 Websocket프로토콜을 사용하고, REST API는 http,https 프로토콜을 사용한다. http는 클라이언트가 연결에대한 요청을 서버로 보내면 서버가 그것에 대한 응답을 보내고 준비가 됐다는 응답까지보내면 데이터를 보내고 이렇게 서로 단방향으로 하나의 연결에 대해서 하나의 처리만 하게 된다.

웹소켓의 경우 클라이언트와 서버가 있을때 연결가능하다는 패킷을 보낸순간부터는 끊겠다고 하기 전까진 계속 연결이 되어있고 지속적으로 요청을 보내고 응답을 받을수 있다 채팅과 관련된것들은 웹소켓을 따르고 있다. 실시간으로 돌아가는것. 방을 나가겠다 하기전까지는 계속 데이터를 받게된다

Chat-GPT 설명

WebSocket 프로토콜과 HTTP 프로토콜은 모두 인터넷에서 사용되는 프로토콜입니다. 하지만 둘은 다른 목적을 가지고 있으며, 다른 방식으로 동작합니다.

HTTP 프로토콜은 일반적으로 클라이언트와 서버 간에 단방향 통신을 제공합니다. 즉, 클라이언트가 서버에 요청을 보내고, 서버가 요청에 대한 응답을 반환하는 방식으로 동작합니다. 또한, HTTP 프로토콜은 요청과 응답 간의 상태를 유지하지 않기 때문에, 클라이언트가 서버와 계속해서 통신하려면 매번 새로운 요청을 보내야 합니다.

반면 WebSocket 프로토콜은 양방향 통신을 제공합니다. 즉, 클라이언트와 서버는 서로 계속해서 데이터를 주고받을 수 있습니다. 이러한 양방향 통신을 위해서 WebSocket 프로토콜은 초기 연결 시에 HTTP 프로토콜을 사용하여 연결을 설정합니다. 이후에는 HTTP 프로토콜과는 달리, 서버와 클라이언트는 계속해서 연결을 유지하며, 언제든지 데이터를 주고받을 수 있습니다.

WebSocket 프로토콜은 실시간성이 중요한 웹 어플리케이션에서 많이 사용됩니다. 예를 들면, 채팅 어플리케이션, 주식 시세 조회 등에서 사용됩니다. 이는 HTTP 프로토콜과는 달리, 클라이언트와 서버 간의 지연 시간을 최소화하고, 빠른 데이터 전송을 가능하게 하기 때문입니다.

REST API

클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의한다. 클라이언트와 서버는 HTTP를 사용하여 데이터를 교환한다. 명확하게 무엇을 하겠다고 메서드로 지시하는것 추상적인 메서드가아니라 명확하게 무슨 작업을 하는지 정확히 표시해주는것.

REST API 사용 이점

데이터자체를 따로 구현할 필요없이 가져가 쓰면된다.
확장: API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공한다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있다. 어느 기업이나 무료 또는 유료 API를 사용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수 있다.

유지 보수 용이: API는 두 시스템 간의 게이트웨이 역할을 한다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 한다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않는다.

API 기획단계

• API 계획: OpenAPI와 같은 API 사양은 API 설계를 위한 블루프린트를 제공합니다. 다양한 사용 사례를 미리 생각하고 API가 현재 API 개발 표준을 준수하는지 확인하는 것이 좋습니다. 이 기능은 어떠한 메서드로 어떠한 리소스 포스트로 해야한다는것과 어떠한 데이터를 반환하고, 실패시 어떠한 데이터를 반환할지에 대한 명세를 하는단계

• API 빌드: API 디자이너는 상용 코드를 사용하여 API 프로토타입을 생성합니다. 프로토타입이 테스트되면 개발자는 내부 사양에 맞게 이를 사용자 지정할 수 있습니다. 만드는 단계

• API 테스트: API 테스트는 소프트웨어 테스트와 동일하며 버그 및 결함을 방지하기 위해 수행되어야 합니다. API 테스트 도구로 사이버 공격에 대비하여 API를 강화할 수 있습니다. 정상적으로 만들어졌는지에 대한 테스트

• API 문서화: API는 그 자체로 설명이 필요 없지만 API 문서는 사용 편의성은 높이는 가이드 역할을 합니다. 다양한 기능과 사용 사례를 제공하는 잘 문서화된 API는 서비스 지향 아키텍처에서 더 많이 사용되는 경향이 있습니다. 사용자가 조금더 쉽게 사용할 수 있도록 문서화. 예시까지 다 포함된다.

• API 마케팅: API 마켓플레이스는 개발자가 다른 API를 사고 팔기 위해 존재합니다. API를 나열하여 수익을 창출할 수 있습니다. OpenAPI에 대한 내용

API EndPoint

API endpoint는 클라이언트가 서버와 통신하기 위한 특정 URL 주소입니다. 간단히 말하면, 서버에서 제공되는 REST API에 대한 URI(Uniform Resource Identifier)입니다. 클라이언트는 이 endpoint를 통해 서버에 요청을 보내고, 서버는 해당 요청에 대한 응답을 반환합니다.

https://api.example.com/v1/users

이 endpoint는 사용자 정보를 조회하기 위한 REST API에 대한 URI입니다. 클라이언트는 이 endpoint를 통해 서버에 사용자 정보를 요청할 수 있습니다. 이때, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 요청의 목적과 방식을 지정합니다.

API endpoint는 서버 측에서 정의되며, 클라이언트가 이를 참조하여 요청을 보낼 수 있습니다. 이를 통해 서버와 클라이언트 간의 통신을 원활하게 처리할 수 있습니다.

REST API 보호방법

모든 API는 적절한 인증 및 모니터링을 통해 보호되어야 한다. 다음은 REST API를 보호하는 두 가지 주요 방법이다.

인증 토큰 : 인증 토큰은 사용자에게 API 호출을 수행할 수 있는 권한을 부여하는 데 사용된다. 인증 토큰은 사용자가 자신이 누구인지 확인하고 해당 특정 API 호출에 대한 액세스 권한이 있는지 확인한다.

API 키 : API 키는 API를 호출하는 프로그램 또는 애플리케이션을 확인한다. 즉, 애플리케이션을 식별하고 애플리케이션에 특정 API 호출을 수행하는 데 필요한 액세스 권한이 있는지 확인한다. API 키는 토큰만큼 안전하지 않지만 사용량에 대한 데이터를 수집하기 위해 API 모니터링을 허용한다.

API Test

여러번 요청을 해보든지, 아주짧은 시간에 많은 데이터를 보내본다.
서버 응답 검증에 주로 초점을 둔다.

API 문서 작성