안녕하세요.

오늘은 REST API에 대해서 포스팅 합니다.

REST 아키텍쳐를 웹 아키텍쳐중 하나인 HTTP 프로토콜과 동일 선상에서 해석하는 자료가 많았습니다.

재밌는 사실은 REST 창시자인 로이 필딩은 HTTP에 대해 전혀 언급하지 않았으며 순수하게 REST 시스템을 구성하는 방법에 대해서만 소개 하였습니다.

이번 포스팅의 목적은 웹과 무관한 REST 시스템을 본질을 이해하고, HTTP 프로토콜을 이용한여 REST 시스템을 설계하는 방법에 대해 이해하는 것 입니다.

REST

REST는 간단하게 말하자면, 존재하는 자원의 식별하고 제어하는 방법론 입니다.

REST 에서 정의 하는 자원에 대한 정의를 알아보고 자원의 제어 자원의 표현은 무엇인지 알아봅시다.

자원 (Resource)

자원이란 일이 처리되는 비용을 의미합니다.

REST 는 소프트웨어 아키텍쳐 이므로 컴퓨터의 자원을 의미합니다.

컴퓨터의 자원은 CPU가 수행하는 명령, 하드디스크에 저장되는 파일들, 메모리에 저장되는 데이터들을 의미합니다.

REST컴퓨터 자원을 사용하여 처리하는 한 단위의 작업을 식별할 수 있어야 합니다.

REST자원을 식별 할 수 있는 식별자가 필요합니다. 예를든다면 TIMESTAMP 나 UUID 같은 중복되지 않는 정보들을 식별자로 사용할 수 있습니다.

자원의 제어 (Resource Methods)

자원의 제어 는 흔히 CRUD 라 부르는 생성, 읽기, 변경, 삭제 행위를 자원에 수행하는것을 의미합니다.

이때 제어 방법은 일관적인 인터페이스로 구성되어야 합니다. 이는 소프트웨어의 API 처리 법칙을 정하면 일관적이게 규칙을 따라야 한다는 것입니다. 예를들어 웹 기반(HTTP)의 시스템에서 자원의 변경을 POST 메소드로 한다면(PUT이 더 어울릴지라도) 자원의 변경은 POST 메소드로 일관적이게 처리해야 한다는 점입니다.

자원의 표현 (Resource Representation)

자원의 표현은 조회한 순간의 자원 상태를 의미합니다. REST 시스템의 자원의 표현자기 서술적인(self-descriptive) 메시지와 HATEOAS(hypermedia as the engine of application state)로 구성됩니다. 이는 데이터를 설명하는 메타 데이터, 다음 자원으로의 이동을 안내하는 하이퍼 텍스트 등이 포함 되는 데이터를 의미합니다. REST 시스템은 클라이언트가 자원의 표현만 보더라도 이해되는 것을 목표로 합니다.


웹 기반(HTTP)의 REST

많은 자료들이 설명하고 있는 REST 시스템은 HTTP 기반으로 구성된 REST 시스템 입니다.

HTTP 기술을 통해 REST 시스템을 어떻게 구현하는지 알아봅시다.

자원의 식별

HTTPREST 시스템이 요구하는 자원의 식별URI의 정의로 처리합니다.

자원은 명사로 커뮤니케이션을 하기 때문에 많은 웹 기반 REST 시스템 선구자들은 URI을 명사구로 표현함으로써 자원을 나타내려고 노력했습니다.

다음과 같은 URI 표기법을 따릅니다.

  • URI의 세그먼트는 동사가 아닌 명사 사용.
    • users/mommoo/name (O)
    • users/mommoo/getName (X)
  • 만약 컨트롤 자원이라면 예외적으로 동사구 허용.
    • users/mommoo/name/duplicate (중복 이름 검사 API)
  • 자원의 관계가 표시되도록 작성.
    • users/mommoo/devices/android-phone
    위 예시는 유저 목록중 Mommoo를 의미하고, Mommoo가 가지고 있는 디바이스들을 의미하며, 디바이스들중 안드로이드 폰을 의미합니다.

자원의 제어

HTTP자원의 제어HTTP Method로 표현합니다. 대표적으로 POST, GET, PUT, DELETE 4개의 Method를 사용 합니다.

자원을 URI로 식별하고 URI에 행위를 붙여줌으로써 자원을 제어합니다.

아래는 자원 제어의 예시입니다.

  • GET users/mommoo/name (이름을 조회합니다.)
  • POST users/mommoo/name (이름을 등록합니다.)
  • PUT users/mommoo/name (이름을 수정합니다.)
  • DELETE users/mommoo/name (이름을 삭제합니다.)

자원의 표현

HTTP는 자원의 표현을 HTTP 응답 메시지로 구현합니다.

REST 자원의 표현의 특징인 self-descriptiveHATEOS를 만족하기 위해 ContentType 또는 커스텀 HTTP 헤더에 메타데이터 명시, 데이터에 링크를 포함하는 등의 기법을 사용합니다.

응답 예시는 https://slides.com/eungjun/rest#/79/0/1 참고해주세요.


REST-FUL

REST 시스템의 구성 요소는 다음과 같이 6개로 구성됩니다.

  • Client-Server
  • Stateless
  • Cacheable
  • Unitform-Interface
  • Layered-System
  • Code on demand (optional)

위 6가지 항목을 만족하는 HTTP REST 시스템을 구현한다고 가정할때, Unitform-Interface 항목을 제외한 나머지 항목들은 자연스럽게 구현이 되거나 조금만 신경을 쓴다면 어렵지 않게 구현할 수 있습니다.

Unitform-Interface 항목은 제외가 됬을까요? Unitform-Interface를 제공하기 위해 수행해야할 특징 중 self-descriptiveHATEOSHTTP 시스템에서 자연스럽게 처리 되지 않기 때문입니다.

사실 self-descriptiveHATEOS 속성은 데이터가 독립적으로 자생하기 위해 필요한 요소들이라 볼 수 있습니다. 그렇다보니 HTTP 서버 스펙을 구현할 때 데이터 독립적인 요소들까지 챙기지 않는 경우도 많습니다. 하지만 REST의 철학을 따르므로 REST 시스템이라 부르고 있습니다.

REST의 구성요소를 완벽하게 지키지 않은 REST 시스템을 구분하기 위해서인지 REST의 구성요소 (특히 Unitform-Interface)를 완벽하게 지킨 REST 시스템을 REST-FUL 시스템이라 부르고 있습니다.

로이 필딩은 REST 시스템의 규칙을 하나라도 제공하지 않는다면 REST 시스템이 아니라고 주장합니다.

정리하자면 REST 시스템으로 소개 되고 있는 시스템은 Unitfor-Interfaceself-descriptiveHATEOS가 지켜지지 않는 경우도 많으며, 나머지 항목까지도 완벽히 구현한 시스템을 REST-FUL 하다고 표현 합니다.


REST-API

API는 컴퓨터의 자원 제어 방법의 집합입니다.

그렇다면 REST-APIREST 시스템의 자원 제어 방법의 집합으로 정의할 수 있습니다.

한단계 더나아가 REST-FUL APIREST의 구성요소를 완벽히 따른 시스템의 자원 제어 방법의 집합이라 정의 할 수 있겠습니다.


오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

참고문헌

https://restfulapi.net/

그런 REST-API로 괜찮은가?

'네트워크' 카테고리의 다른 글

[네트워크] OSI 7계층  (0) 2021.07.26
[네트워크] HTTPS 프로토콜  (1) 2021.07.16

포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.

Buy me a coffeeBuy me a coffee

안녕하세요.

오늘은 HTTPS 통신 에 대해 포스팅 합니다.

HTTPS 통신 은 데이터를 암호화 하여 통신하도록 설계되어 보안적인 요소가 강화된 HTTP 통신 입니다.

HTTPS 통신HTTP 통신 과 다르게 서버가 제공하는 SSL 인증서 라는 요소가 추가되었으며, 이를 통해 클라이언트는 필요한 서버의 정보를 취득하고 신뢰성을 판단합니다.

데이터 암호화

HTTPS 통신 방법에 앞서, 간단하게 데이터 암호화 개념을 살펴보면 좋습니다.

암호화 란 평문을 암호문으로 변경하는것을 의미합니다.

반대로 복호화 는 암호문을 평문으로 변경하는것을 의미합니다.

평문: 사람이 이해할 수 있는 데이터

암호화는 어떤 특정 데이터를 사용하여 수행하는데, 이 특정 데이터를 암호키 라고 부릅니다.

암호화는 크게 두가지 방식이 있습니다.

  • 대칭키 방식
  • 공개키 방식

대칭키 방식

대칭키 방식은 말그대로 암호키 가 대칭임을 의미 합니다.

암호화 할때도, 복호화 할때도 똑같은 1개의 암호키 를 사용하는 것이 특징입니다.

통신 하려는 대상 서로가 암호키 를 알고 있으면 매우 유용합니다.

하지만 불특정 다수와 통신을 하기 위한 안전한 암호키 전달이 무척 어렵습니다.

해커가 중간에 암호키 를 취득 해버리면 데이터를 암호화 하는게 의미가 없기 때문입니다.

Q. 암호키암호화 해서주면 안되나요? A. 암호화 를 하기위해서는 무조건 최초로 평문으로된 암호키 를 넘겨주어야만 합니다. 암호키암호화 해버리면 클라이언트는 복호화 를 할 수 있는 키를 모르기 때문입니다.

공개키 방식

공개키 방식은 암호키 가 두가지 존재합니다.

  • 공개키
  • 비공개키(개인키, 비밀키)

대칭키 방식 과는 다르게 암호화 할때 공개키를 사용했으면 복호화비밀키 를 사용해야 합니다.

반대로, 암호화 할때 비밀키 를 사용했다면 복호화공개키 로만 가능합니다.

공개키 방식의 장점

공개키 방식대칭키 방식 의 키를 안전하게 전달하기 어려운 단점을 어느정도 해소 하였습니다.

서버가 개인키 를 소유하고 있고, 불특정 다수에게 공개키 를 전달합니다.

이때, 해커가 공개키 를 획득 할 수 있고 그로인해 서버가 내려주는 데이터 를 해석은 할 수 있지만 클라이언트에게 공격하지는 못합니다.

예를들어, 서버가 클라이언트에게 A의 장소 를 알려줬습니다. 이때 해커는 공개키 를 취득해 복호화 하여 내용을 읽었고 클라이언트에게 B의 장소 로 속이고 싶습니다.

해커가 데이터를 변경하더라도 서버가 가지고 있는 비밀키 를 알아야 클라이언트가 속을 수 있는 암호문 을 만들 수 있습니다.

해커가 임의로 암호문을 만들어버리면 클라이언트는 공개키 로 복호화에 실패할것이고, 결국 클라이언트에게 공격하지 못하는 상황이 발생합니다.

물론 클라이언트가 서버의 서비스를 이용 못하는건 있습니다. 하지만 공격 받지 않는것이 핵심입니다.

반대로 클라이언트가 서버로 데이터를 보낼 때는 공개키 로 데이터를 암호화 하여 보냅니다.

해커는 공개키 만알고 있기 때문에 클라이언트 데이터를 읽지 못합니다. 왜냐면 공개키 방식공개키암호화 를 하면 비밀키 로만 복호화 를 진행할 수 있기 때문입니다.

정리하자면 공개키 방식 은 클라이언트로 하여금 데이터가 변경되지 않음을 보장할 수 있고 안전하게 데이터를 서버로 보낼 수 있는 장점이 있습니다.

공개키 방식의 단점

하지만 공개키 방식도 한계가 존재합니다. 클라이언트 → 서버로 데이터를 암호화 해서 보내는건 문제가 되지 않습니다. 해커가 읽지도 못하니깐요.

하지만 서버 → 클라이언트로 보내는 데이터는 해커가 읽을 수 있습니다. 만약 데이터가 민감한 개인 정보같은게 포함되어 있다면 해커가 읽는것만으로도 피해가 생길 수 있기 때문입니다.

또한 공개키 방식대칭키 방식 보다 암-복호화 속도가 느립니다.

SSL 인증서

HTTPS 통신 에서는 서버가 SSL 인증서 를 제공한다고 언급했습니다.

SSL 인증서는 크게 두가지 역할을 수행합니다.

  • 서버 본인이 신뢰할 수 있는 서버임을 증명하는 수단.
  • 서버가 제공하는 공개키를 전달.

SSL 인증서 는 서버의 신뢰성을 판단할 수 있는 수단이라 했는데, 다짜고짜 클라이언트에게 SSL 인증서 를 내밀면 신뢰할 수 있을까요?

예를들어, 모르는 사람이 다가와서 나 믿을 수 있는 사람이야 라고 말하면 여러분을 믿을 수 있으신가요?

그렇기에 SSL 인증서 의 신뢰성을 대신 보장하는 제 3자가 존재합니다.

그 3자를 CA(Certificate authority) 혹은 Root Certificate 라 일컫는 기업들입니다.

해당 기업들은 세계적인 기업으로써, 신뢰성이 엄격하게 공인된 기업들만 CA로써, 참여할 수 있습니다.

이러한 기업은 SSL 인증서 를 신청한 기업들이 신뢰성있는 기업인지 평가한 후 발급을 진행합니다.

CA 기업들은 잘 알려진 기업들로써, HTTPS 통신을 지원하는 클라이언트(대표적으로 브라우저)들은 CA 리스트 를 보유하고 있습니다. 그렇기에, 클라이언트는 SSL 인증서 를 받은 후 정보를 읽어 CA 리스트 대조를 통해, CA 가 발급한 SSL 인증서 의 유무를 판단하고 신뢰성을 평가합니다.

CA 가 발급하지 않은 SSL 인증서 는 클라이언트가 신뢰성을 낮게 평가합니다.

SSL 인증서 암호화

SSL 인증서는 비공개키 방식 으로 암호화하여 클라이언트에게 전달됩니다.

이때, 암호화 를 수행하는 대상은 서버가 아닌, CA 에서 자체적으로 소요한 비밀키 를 통해 암호화 를 진행합니다.

SSL 인증서 를 서버에서도 변조하여 클라이언트에게 공격할 수 없습니다. 비밀키 를 모르기 때문입니다.

CA공개키는 이미 널리 알려진 정보로써, 클라이언트가 CA 리스트 와 함께 공개키 도 보유하고 있습니다. 그렇기에 위에 앞서 언급한 공개키 방식 장점을 잘 활용하고 있다고 볼 수 있습니다. SSL 인증서 가 위조되지 않음을 보장받을 수 있기 때문입니다.

SSL 인증서에 포함된 공개키

SSL 인증서엔 공개키가 포함되어 있는데 이는, CA공개키가 아닙니다. 서버가 클라이언트와 보안 통신을 하기위해 서버가 직접 생성한 공개키 입니다.

서버가 CA 에게 SSL 인증서 의 발급 신청을 할 때, 몇몇 서버 데이터를 전달하는데 필수적으로 공개키 도 전달이 되어야 합니다.

뒤에 설명할 SSL 통신 에서는 클라이언트가 SSL 인증서 를 통해 서버의 공개키 를 취득하고, 비공개 방식 으로 보안 통신하는 절차가 있기 때문에 필수적으로 필요합니다.

SSL 통신

공개키 방식 으로 통신을 하면, 서버 → 클라이언트로 데이터를 내려줄땐 조금 문제가 될 순 있지만, 어느정도 감안하고 보안 통신 방법으로 사용할 수 있을거 같습니다.

하지만, 큰 단점이 있는데요.

그것은 바로 공개키 방식은 암호화 복호화 하는 과정이 느리다 라는 것 입니다.

웹통신이 느리면, 문제가 될 수 있기 때문에 SSL 통신 은 상대적으로 빠른 대칭키 방식 으로 메인 통신을 진행합니다.

하지만, 대칭키는 공격자가 알면 너무나도 쉽게 데이터를 변조하여 대상을 속일 수 있기 때문에 매우 위험합니다. SSL 통신은 어떻게 이런 이슈들을 해결했을까요?

SSL 통신 방법

결론적으로 말하자면, SSL 통신은 공개키 방식대칭키 방식 둘 다 사용합니다.

SSL 통신은 다음의 아이디어를 사용합니다.

공개키 방식 으로 서버와 함께 작성된 대칭키 를 서로에게 전달합니다. 이때 중간 공격자는 서버의 개인키 를 알고있지 않는한 내용을 복호화하지 못하여 데이터 해독이 불가능 합니다.

이렇게 서로 안전하게 대칭키 가 전달되었다면, 암-복호화가 빠른 대칭키 로 데이터 통신을 합니다.

SSL 통신 절차

TCP와 같은 연결지향 프로토콜은 크게 아래의 과정을 거칩니다.

  • 악수(HandShake)
  • 데이터 전송(세션)
  • 세션 종료

SSL 통신도 결국 TCP위에서 동작하므로, 위 과정과 같습니다만, 세부적인 내용이 조금 다릅니다.

SSL 통신은 TCP의 핸드쉐이크 (SYNSYN ACKACK) 과정이 이루어 진 후에, SSL 통신이 시작됩니다. (악수 → 데이터 전송 → 세션 종료)

악수(HandShake)

  1. Client Hello (클라이언트가 서버에 접속합니다. )
    • 서버에게 평문 문자열 Client Hello 를 전송합니다.
    • 서버에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송 합니다.
  1. Server Hello (서버가 Client Hello 를 받은 후, 클라이언트에게 응답합니다.)
    • 클라이언트에게 평문 Server Hello 를 전송합니다.
    • 클라이언트에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송합니다.
    • 제일 중요한 SSL 인증서 를 전송합니다.
  1. 클라이언트의 SSL 인증서 신뢰성 판단
    • 서버에게 받은 SSL 인증서 를 보유하고 있는 CA 리스트를 통해 복호화 합니다.
    • 복호화 에 성공하였다면, 해당 서버를 신뢰할 수 있다고 판단합니다.
  1. 서버에 대칭키 전송 (SSL 핸드쉐이크의 핵심 목적 입니다.)
    • 클라이언트는 본인이 만든 랜덤 데이터와 서버에서 받은 랜덤 데이터를 이용하여, 대칭키 를 구성합니다.
    • 해당 대칭키를 SSL 인증서 에 포함되어 있는 서버 공개키암호화 하여 서버에게 전송합니다.
  1. 핸드쉐이크 종료
    • 클라이언트와 서버가 서로 대칭키 를 안전하게 전달 받은 후, 통신 준비가 되었다는 신호와 함께 핸드쉐이크가 종료됩니다.

데이터 전송(세션)

서버와 클라이언트가 데이터를 서로 주고 받고 하는 단계입니다. 서로 안전하게 전달받은 대칭키 를 사용하여, 암-복호화를 빠르게 진행합니다.

세션종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려줍니다.

오늘 준비한 포스팅은 여기까지 입니다. 읽어주셔서 감사합니다.

'네트워크' 카테고리의 다른 글

[네트워크] REST API  (0) 2021.08.08
[네트워크] OSI 7계층  (0) 2021.07.26

포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.

Buy me a coffeeBuy me a coffee

오늘 포스팅 할 내용은, 


Http 프로토콜이 제공해주는 7가지 메서드들 중


웹서비스 개발에 주로 사용하는,

GET 메서드와 POST 메서드에 대하여 기술한다.




GET메서드 POST메서드 란?



  위에서 말했다시피, 웹 서비스 개발에 주로 사용하는 메서드 이다.


사용자가 URL을 브라우저 주소창에 작성하고 엔터를 누르면


원하는 웹페이지가 나온다. 사용자는 웹페이지를 보기위해 단순한 일을 한 것 이지만,

특정 웹페이지를 사용자 웹브라우저에게 보여주기 위해서는 내부적인 처리들이 있다.


그 내부적인 처리에서, 클라이언트가 서버에게 웹페이지를 보여달라고 말하는 것을


우리는 요청 이라 부르고, 서버가 클라이언트에게 요청받은 것에 대한 대답으로, 웹페이지


내용을 표현하기 위해 html문서로 주는것을 응답 이라 부른다. 




HTTP 패킷



  클라이언트가 서버로 요청을 했을때, 보내는 데이터를 HTTP 패킷이라 표현한다. 


HTTP 프로토콜을 쓰므로, 앞에 HTTP가 붙고 인터넷을 통해 보내는 데이터를 패킷이라 표현하므로,


HTTP패킷 이라 부른다. HTTP패킷의 구조는 크게 헤더 바디로 나뉘어진다.



  헤더에는 7가지 HTTP 메서드 방식중 무엇을 썻는지, 클라이언트의 정보, 브라우저 정보,


접속할 URL 등등 과 같은 클라이언트 정보를 담는다. 

  

바디는 보통 비어있다. 하지만, 특정 데이터를 담아서 서버에게 요청을 보낼 수 있다.


이러한 웹 개념아래, 우리는 GET메서드와 POST메서드를 통해서 요청을 할 수 있다.




GET방식 vs POST방식


  

  두 방식 모두, 서버에 요청을 하는 메서드이다.


클라이언트가 서버에 요청을 할때, 제공해야 하는 자원이 있다고 하자. 


예를 들면, 어떤 홈페이지의 로그인 페이지에서 로그인을 하는 경우이다.


아이디 와 패스워드는 클라이언트가 작성한 후, 그 정보를 서버에 요청하여


클라이언트가 작성한 아이디와 패스워드가 올바른 것인지 검사를 해야한다.


위의 예시를 보듯, 요청에는 자원을 보내야 하는경우가 존재한다.


  • GET방식으로 데이터를 보내기

클라이언트의 데이터를 URL뒤에 붙여서 보낸다. 위에서 쓴 예시처럼 아이디 패스워드를 보낸다고 하면,


www.example.com?id=mommoo&pass=1234 (예시로 쓴 URL입니다. 존재하지 않습니다.)


이런식으로 보낸다. URL 뒤에 "?" 마크를 통해 URL의 끝을 알리면서, 데이터 표현의 시작점을 알린다.


데이터는 key 와 value 쌍으로 넣어야 한다 윗 예시에서의 key는 id 랑 pass고 value는 mommoo랑 1234가 되겠다.

중간에 &마크는 구분자 이다. 2개이상의 key - value 쌍 데이터를 보낼때는 &마크로 구분해준다.


URL에 붙이므로, HTTP패킷의 해더에 포함되여 서버에 요청한다.


따라서, GET 방식에서 BODY에 특별한 내용을 넣을 것이 없으므로 BODY가 빈상태로 보내진다.


그러므로, 헤더의 내용중 BODY 데이터를 설명하는 Content-Type이라는 헤더필드는 들어가지 않는다.


URL형태로 표현되므로, 특정 페이지를 다른사람 에게 접속하게 할 수 있다. 


또한 간단한 데이터를 넣도록 설계되어, 데이터를 보내는 양의 한계가 있다.


  • POST방식으로 데이터를 보내기

POST 방식은 GET 방식과 달리, 데이터 전송을 기반으로 한 요청 메서드이다.


GET방식은 URL에 데이터를 붙여서 보내는 반면, POST방식은 URL에 붙여서 보내지 않고


BODY에다가 데이터를 넣어서 보낸다.  


따라서, 헤더필드중 BODY의 데이터를 설명하는 Content-Type이라는 헤더 필드가


들어가고 어떤 데이터 타입인지 명시한다.


컨텐츠 타입으로는 여러가지가 있지만, 몇가지를 적자면,


  1. application/x-www-form-urlencoded
  2. text/plain
  3. multipart/form-data

등이 있다.

따라서 POST 방식으로 데이터를 보낼때는 위와 같이 컨텐츠 타입을 꼭 명시해줘야한다.

보통 작성하지 않는 경우는 1번의 컨텐츠 타입으로 셋팅된다.

1번의 컨텐츠 타입은, GET방식과 마찬가지로 BODY에 key 와 value 쌍으로 데이터를 넣는다. 똑같이 구분자 &를 쓴다.

2번의 컨텐츠 타입은, BODY에 단순 txt를 넣는다.

3번의 컨텐츠 타입은, 파일전송을 할때 많이 쓰는데 BODY의 데이터를 바이너리 데이터로 넣는다는걸 알려준다.

자바와 같이 oop 프로그래밍에서는 BODY에 데이터를 InputStream/OutputStream 클래스를 통해서 읽고/쓰고 한다.


GET방식 과 POST방식에 대한 상식
  • POST방식이 GET방식보다 보안측면에서 더 좋다?
   POST든 GET이든 보내는 데이터는 전부 클라이언트측에서 볼 수 있다. 단지 GET방식은 URL에 데이터가 표시되여 별다른 
   
   노력없이 볼 수 있어서지, 두 방식 전부 보안을 생각한다면 암호화 해야한다.

  • GET방식이 POST방식보다 속도가 빠르다?
    빠른건 맞다. 하지만 왜 빠른지를 알아야 하는데, 이유는 GET방식의 요청은 캐싱(한번 접근 후, 또 요청할 시 빠르게 접근하기 위해
    
    데이터를 저장시켜 놓는다)때문에 빠른것이다.
   




'용어정리 > 프로그래밍용어' 카테고리의 다른 글

비즈니스 로직(Business Logic)이란?  (15) 2017.05.24
DTO와 VO란?  (2) 2017.02.08
컴포넌트(Component)란?  (8) 2016.10.20
URL 이란?  (2) 2016.06.14
URI 이란?  (0) 2016.06.13

포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.

Buy me a coffeeBuy me a coffee

+ Recent posts