공부를 하던 중에 원래는 거의 동일하다고 알고만 있던 REST와 HTTP API가 다르다는 걸 봐서 한번 정리 해볼까 한다.

우선 두개의 API의 개념을 확립하기 위해서는 API에 대해 먼저 알아보자

📡API

API는 Application Programming Interface의 약자로 컴퓨터 혹은 컴퓨터 프로그램끼리의 연결, 즉 컴퓨터 혹은 컴퓨터 프로그램끼리 소통을 의미한다.이러한 소통을 어떻게 할 지 문서로 정리하거나 공통의 기준을 정한 것을 API  명세라고 한다. 

한 컴퓨터/프로그램이 소통하는 방식이 상대방 컴퓨터/프로그램과 다를 수 있기 때문에, 서로가 공통적으로 이해할 수 있는 기준을 명시한 것이다.

REST API와 HTTP API는 웹에서의 소통에 사용되기 때문에 WEB API에 해당한다. WEB API는 웹에서의 통신을 기반으로 하는 API이다. 소통을 하기 위해서는 웹을 통해 소통하는 방식(Method), 어떤 자원(Resource)들에 대해서 소통할 것인가 등에 대한 기준이 추가로 필요하다.

📡HTTP API

HTTP(Hypertext Trasnfer Protocol)API는 두 시스템 간의 통신 프로토콜로 Hypertext Transfer Protocol을 사용하는 API이다.HTTP API는 endpoint를 API gateway로 활용하여, HTTP 요청을 통해서 서버에 접근할 수 있도록 만들어준다.

📡REST API

REST는 Representational State Transfer의 약자로 클라이언트와 서버 간에 데이터를 공유하기 위한 모범 사례를 정의하는 규칙의 집합이다. 본질적으로 복잡성에 관계없이 CRUD 기능만 사용하도록 요청하는 HTTP 또는 다른 API를 만들 때 사용되는 디자인 스타일이다.

REST한 프로그램이 되려면 CRUD 방식의 메서드, HTTP 메서드 중에 GET,POST,DELETE,PUT 만을 사용한다.

메서드의 일부를 무시하는 것이 직관적이지 않은 것처럼 보일 수 있지만 궁극적으로 복잡한 동작을 간단한 용어로 설명해야 한다.이런식으로 메서드를 제한 했을때 , 인터페이스가 단순해지고 추후 확장도 쉽다는 장점이 생기고, 더 간단한 방법과 다른 RESTAPI와의 더 쉬운 통합으로 이어진다.

다음으로 모든 HTTP API가 REST API는 아니기 때문에, REST API로 간주되기 위해 다음 요구사항을 충족해야 한다.

• Client-Server
  • REST 애플리케이션에는 애플리케이션 데이터와 상태를 서버가 관리한다. 서버는 사용자 상호작용을 처리하는 클라이언트와 통신한다.
  • 서버와 클라이언트를 분리하면서, 클라이언트와 서버를 독립적으로 관리하고 업데이트가 가능하다.
• Stateless
  • 클라이언트의 상태는 자체적으로 관리된다.클라이언트가 서버에 보내는 요청은 요청을 실행하기 위한 모든 정보를 포함해야한다.
• 캐시화 가능
  • 서버는 응답을 캐시 가능 여부로 표시해야 한다. 시스템과 클라이언트는 성능을 향상시키기 위해 편리할 때 응답을 캐시할 수 있다.
  • 또한 캐시할 수 없는 정보를 없애므로 오래된 데이터를 사용하지 않는다.
• 균일한 인터페이스
  • REST의 가장 잘 알려진 특성이다. REST 서비스는 일관된 네임 스페이스를 사용하여 데이터를 리소스로 제공한다.
• 계층화된 시스템
  • 구성요소들은 서로의 계츨 너머를 볼 수 없다.각각의 범위가 제한되므로 개발자들이 인증 관현 보안을 강화하거나 성능을 개선하기 위해 로드 밸런서나 프록시를 추가하는 것이 쉽다.

⛏정리 

REST API와 HTTP API는 거의 비슷한 개념으로 사용되고 있는거 같지만 REST API와 HTTP API는 엄밀히 말하면 다르다.

REST API는 HTTP API에 여러가지 제약조건이 추가된 것이다. 그런데 까다로운 제한이 추가되는데도 불구하고 REST API를 사용하는 이유는 애플리케이션을 만들 때 이런 특성들을 혼합하면, 견고한 경계를 가지면서 관심사가 잘 분리된 구조로 만들 수 있다.

클라이언트는 서버에 요청을 했을때만 데이터를 받아 그 데이터를 가공하거나 표시하는데 활용한다. 만약 클라이언트의 상태가 변경된다면 서버에 알린다. REST API에서 데이터가 구현되는 과정은 클라이언트가 알 수 없지만 , 데이터 그 자체를클라이언트에게 숨기지는 않는다.

REFERENCE

• https://www.educative.io/blog/what-are-rest-apis

📡HTTP메서드 종류

• GET : 리소스 조회
• POST :요청 데이터 처리, 주로 등록에 사용한다.
• PUT : 리소스를 대체 , 해당 리소스가 없으면 생성한다.
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제 

➡️GET 

• 리소스를 조회할 때 사용한다.
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달한다.
• 메시지 바디를 통해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 믾아서 권장하지 않는다.
• 메시지 전달 -> 서버 도착 -> 응답 데이터 반환

➡️POST

• 요청 데이터를 처리한다.
• 메시지 바디를 통해 서버로 요청데이터를 전달한다.
• 서버는 요청 데이터를 처리한다.
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록 , 프로세스 처리(요청 데이터 처리)에 사용한다.
• 다른 메서드로 처리하기 애매한 경우에는 POST를 사용한다.
• 메시지 전달 -> 신규 리소스 생성 ->응답 데이터 반환 

➡️PUT

• PUT은 리소스를 대체한다.
• 리소스가 없으면 신규로 생성하고, 있으면 대체한다.
• 클라이언트가 리소스 위치를 알고 URI를 지정해서 사용한다.
• 리소스를 완전히 대체한다.
• 만약 리소스가 {"username" : " young" , "age": 30} 일때
• PATCH로 {"age":50}을 요청하면 {"age": 50}으로 변경된다.("username"은 사라진다.)

➡️PATCH

• PATCH는 리소스를 부분 변경한다.
• 만약 리소스가 {"username" : " young" , "age": 30} 일때
• PATCHfh {"age":50}을 요청하면 {"username" : " young" , "age": 50}으로 변경된다.

➡️DELETE

• 리소스를 제거 한다.

➡️기타 메서드

• HEAD :  GET과 동일하지만 메시지 부분을 제외하고 , 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명한다.
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 

📡HTTP메서드의 속성 

➡️멱등 

• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
• GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. 
• DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다. 
• POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

➡️캐시가능

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시가능 실제로는 GET, HEAD 정도만 캐시로 사용
• POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

📡HTTP란?

• HTTP는 HyperTextTransferProtocol의 약자로 하이퍼텍스트 문서를 교환하기 위하여 사용된 통신 규약이다.
• 웹 서버와 클라이언트 간의 통신을 하기 위한 통신 규약이다.
• HTTP는 1989년 팀 버너스 리에 의해 처음 설계되어 인터넷을 통한 월드 와이드 웹 기반에서 전 세계적인 정보 공유를 이루는데 큰 역할을 했다.
• HTTP는 웹에서만 사용하는 프로토콜로 TCP/IP기반으로 한 지점에서 다른지점(서버와 클라이언트)으로 요청과 응답을 전송한다.

📡HTTP의  특징

• HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해서 해석이 된다.
• TCP/IP를 이용하는 응용 프로토콜(application protocol)입니다.HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다. (이러한 단점을 해결하기 위해 Cookie와 Seesion 등장)
• HTTP는 연결을 유지하지 않는 프로토콜이기 떄문에 요청/응답(request/response) 방식으로 동작한다.
  
  
  

클라이언트(client) 즉, 사용자가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request)을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.

- 요청 : client -> server

- 응답 : server -> client

📡HTTPS란?

HyperText Transfer Protocol over (SSL)Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리는 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 433번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다.

HTTPS는 TCP위에 놓인 보안계층(SSL)위의 HTTP이다

공개키/개인키

HTTPS는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화 한다.공개키와 새인키는 서로를 위한 1쌍의 키이다.

• 공개키 : 모두에게 공개가능한 키
• 개인키 : 나만 가지고 알고 있어야하는 키

공개키와 개인키로 암호화하면 얻을수 있는 효과

• 공개키 암호화 : 공개키로 암호화를 하면 개인키로만 복호화를 할 수 있다. => 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
• 개인키 암호화 : 개인키로 암호화하면 공개키로 복호화를 할 수 있다.  =>공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

SSL(Secure Socket Layer)?

SSL 디지털 인증서 =>클라이언트와 서버간의 통신을 공인된 제3자업체가 보증해주는 전자화된 문서이다.

SSL 디지털 인증서의 장점

• 통신 내용이 노출, 변경되는 것을 방지한다.
• 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지 확인이 가능하다.
• SSL 통신에 사용할 공개키를 클라이언트에게 제공한다. 

SSL에서 사용하는 암호화의 종류 

• 암호 : 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
• 키 : 암호의 동작을 변경하는 매개변수, 키에 따라서 암호화 결과가 달라지기 떄문에 키를 모르면 복호화가 불가능하다.

CA : https://ko.wikipedia.org/wiki/인증_기관

인증서 내용

• 인증서의 내용은 CA의 비공개 키를 이용해서 암호화 되어 웹브라우저에게 제공된다.
• 서비스 정보 (인증서 발급자, CA의 디지털 서명,서비스 도메인)
• 서버측 공개키

SSL 인증서의 서비스 보증방법

• 웹브라우저가 서버에 접속하면 서버는 제일 먼저 인증서를 제공한다.
• 브라우저는 인증서를 발급한 CA가 자신이 갖고있는 CA 리스트에 있는지 확인한다.
• 리스트에 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화 한다.
• 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미한다. 즉 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다.

SSL 동작방법

• 공개키 암호 방식은 알고리즘 계산방식이 느린 경향이 있다.
• 따라서 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키 암호화 방식을 혼합하여 사용한다.
• 안전한 의사소통 채널을 수립할 때는 공개키 암호를 사용하고, 이렇게 만들어진 안전한 채널을 통해서 임시의 무작위 대칭키를 생성 및 교환한다. 해당 대칭키는 나머지 데이터 암호화에 활용한다.

SSL 통신과정

• 컴퓨터와 컴퓨터가 네트워크를 통해서 통신을 할때 핸드쉐이크 -> 세션 -> 세션종료 의 과정을 거친다.
• 암호화된 HTTP 메시지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행한다.

📡 HTTP와 HTTPS

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다. 하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리다.또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생하다.

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 단순한 정보 조회 등만을 처리하고 있다면 HTTP를 이용하면 된다.

REPERENCE

• https://toma0912.tistory.com/69
• https://mangkyu.tistory.com/98
• https://ko.wikipedia.org/wiki/인증_기관
• https://wayhome25.github.io/cs/2018/03/11/ssl-https/

상태코드

• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

#1XX(Informational) ->요청이 수신되어 처리중 

#2XX(successful) ->성공 (클라이언트 요청을 성공적으로 처리)

• 200 OK
• 201 Create =>(요청 성공 해서 새로운 리소스 생성)
• 202 Accepted  =>(요청이 접수되었으나 처리가 완료되지 않았음)
• 204 No Content  =>(요청은 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음)

#3xx (Redirection) -> 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

                                    ->웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

   리다이렉션의 종류

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동(예) /event -> /new-event )
• 일시 리다이렉션 - 일시적인 변경(주문 완료 후 주문 내역 화면으로 이동,PRG: Post/Redirect/Get)
• 특수 리다이렉션 - (결과 대신 캐시를 사용)

• 300 Multiple Choices
• 301 Moved Permanently ->리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
• 302 Found ->리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
• 303 See Other ->302와 기능은 같음, 리다이렉트시 요청 메서드가 GET으로 변경
• 304 Not Modified ->캐시를 목적으로 사용
  
• 307 Temporary Redirect ->302와 기능은 같음 ,리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
• 308 Permanent Redirec ->301과 기능은 같음, 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

#4xx (Client Error) ->클라이언트 오류

• 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 오류의 원인이 클라이언트에 있음

@400 Bad Request ->(클라이언트가 잘못된 요청을 통해서 서버가 요청을 처리할 수 없음 )

• 요청 구문, 메시지 등등 오류
• 클라이언트는 요청 내용을 다시 검토하고,보내야함 

@401 Unauthorized ->(클라이언트가 해당 리소스에 대한 인증이 필요함 )

• 인증(Authentication) 되지 않음
• 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

@403 Forbidden ->(서버가 요청을 이해했지만 승인을 거부함)

• 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
• 예) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

@404 Not Found ->(요청 리소스를 찾을 수 없음)

• 요청 리소스가 서버에 없음
• 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

#5XX(Server Error) ->서버 오류

• 서버 문제로 오류 발생
• 서버에 문제가 있기 때문에 재시도 하면 성공 할 수도 있음

@500 Internal Server Error 

• 서버 문제로 오류 발생, 애매하면 500 오류

@503 Service Unavailable

•  서비스 이용 불가
• 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음 Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음