int와 short
두 가지 모두 정수형 타입이다. 그렇다면 어떤 차이가 있는지 알아보자.
- char, short 형 : 이와 같은 정수 자료형 타입으로 표현하면 메모리 공간을 효율적으로 사용할수는 있으나 연산의 효율성은 떨어진다.
- size : 2byte(16bits)
- int 형 : int형보다 작은 크기의 데이터를 가지고 연산을 진행할 경우, 그 데이터를 일단 int형으로 바꿔서 연산을 진행한다. 따라서 산술 연산시, 자료형을 int형으로 선언해야 중간에 불필요한 변환 과정을 거치지 않게 되어 연산 효율이 좋다.
- size : 4byte(32bits)
int (Primitive) vs Integer (Wrapper Class)
1. Primitive 자료형 - Wrapper 클래스 관계
|
int |
primitive 자료형 (long, float, double ...) |
| 산술 연산이 가능하다. | |
|
null로 초기화 할 수 없다. |
|
|
Integer |
Wrapper 클래스 (객체) |
|
Unboxing을 하지 않으면 산술 연산이 불가능 하지만, null 값을 처리할 수 있다. |
|
|
null 값 처리가 용이하기 때문에 SQL과 연동할 경우 처리가 용이하다. |
|
|
DB에서 자료형이 정수형이지만 null 값이 필요한 경우 VO에서 Integer를 사용할 수 있음. |
2. int와 Integer간의 변환
- Boxing과 Unboxing이라고 한다.
|
Boxing |
Primitive 자료형 -> Wrapper 클래스 |
|
Unboxing |
Wrapper 클래스 -> Primitive 자료형 |
- 예제 코드
// to int i from Integer ii
int i = ii.intValue();
// to Integer ii from int i
Integer ii = new Integer( i );
- valueOf()와 parseInt()의 차이
|
Integer.valueOf(String) |
Integer 클래스를 리턴하기 때문에 산술 연산을 할 수 없다. |
|
Integer.parseInt(String) |
int 형을 리턴하기 때문에 산술 연산을 할 수 있다. |
※ 정수로 파싱할 수 없는 String을 파라미터로 전달하면 에러
3. Auto boxing / unboxing
- 자바에서는 모든 경우는 아니지만 대부분의 경우에는 자동으로 boxing / unboxing을 해준다.
- 예제 코드
int i = 1; Integer integer = i;
// int -> Integer (Auto boxing)
int i2 = integer;
// Integer -> int (Auto unboxing)
4. int와 Integer의 사이즈를 비교하는 재미있는 실험
- 환경
|
JRE |
jdk 1.5.0_15 |
|
OS |
Windows XP |
- 조건
|
Integer 및 int 배열을 1,000,000개 생성 |
- 결과
|
Integer |
19986824 byte |
|
int |
3998536 byte |
|
Rate(Integer/int) |
4.99 (약 5배) |
- 요약
|
- Object가 8 byte - Integer가 16 byte - Integer를 참조하는데 4 byte - Integer의 사이즈 = 16 + 4 = 20 byte - int의 사이즈 = 4 byte -> 5배 차이 |
출처: https://includestdio.tistory.com/1 [includestdio]
CORS란 무엇일까?
처음에는 CORS가 다른 도메인으로의 자원 요청을 하지 못하도록 하는 것인줄 알았다. 실제로도 누군가 물어볼때 이와 같이 이야기했다.사실 위의 얘기는 SOP(Same Origin Policy)였다.
CORS란 Cross Origin Resource Sharing의 약자이다, 직역하자면 Origin(host)를 가로질러 자원에 접근 할 수 있는 권한을 부여하도록 브라우저에 알려주는 정책이다.
예를들어 우리가 www.naver.com 웹페이지에서 api.daum/post/123 과 같은 api를 호출했다고 하자, 이 경우에 원하고자 했던 자원에 대한 출처는 api.daum이 된다.
위 그림처럼 현재 출처가 네이버인 상황에서 Daum의 API 서버로의 리소스 요청은 브라우저의 SOP(Same Origin Policy)에 의해 제한된다. 즉 위 API를 사용하는 웹 어플리케이션은 자신의 출처와 동일한 리소스만 불러 올 수 있으며, 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야만 한다.
즉, 자원을 요청한 출처(naver)와 해당 요청을 응답하는 서버의 출처(daum)이 다를 경우에도 해당 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게 알려주는 정책이다.
브라우저는 보안상의 이유로 스크립트에서 시작된 교차 출처에 대한 HTTP 요청을 제한한다.
출처(Origin)란 무엇일까?
우리가 흔히 알고있는 URL은 다양한 요소로 구성되어 있다.
https://blog.naver.com/dnvld1/?page=1 라는 URL이 있다고하면 이는 아래와같이 구성되어 있습니다.
- https:// -> protocol
- blog.naver.com -> domain
- /dnvld1 -> path
- /?page=1 -> query string
출처란 프로토콜을 포함한 도메인을 의미합니다. (이 도메인에는 port번호가 포함되어 있으며, port가 다른경우에도 다른 출처로 봅니다.)
SOP (Same Origin Policy)
SOP란 같은 출처 정책으로, 말 그대로 같은 출처에 대한 HTTP 요청만을 허락하는 것으로, 웹 어플리케이션에서의 중요한 보안 모델이다. 보통 자바스크립트에 의한 데이터 접근에 해당하는 정책이며, HTML 태그를 통한 이미지, CSS, Script 요청은 SOP에 의해 제한되지 않는다.
위에서 보안상의 이유로 다른 출처로의 스크립트 HTTP 요청을 제한한다고 했지만. 실제로 웹을 개발하다보면, 다른 출처의 HTTP요청을 해야만 하는경우가 너무나도 많습니다. 따라서 몇가지 예외 조항을 두어 이에 해당하는 리소스 요청은 출처가 다르더라도 허용하기로 결정되었는데 그중 하나가 CORS 정책을 지킨 리소스의 요청은 허락하는 것이다.
접근 제어의 시나리오 예제
CORS가 동작하는 방식으로는 세가지가 있다. 바로 단순요청, 프리플라이트(preflight) 요청, 그리고 인증정보를 포함하는 요청이 그것이다.
1. 단순요청 (Simple Request)
이 요청은 CORS의 preflight를 트리거하지 않고 단순히 요청을 하고, 이 요청은 아래와 같은 조건이 설정되었을때 발생합니다.
- GET, HEAD, POST에 해당하는 HTTP 메소드
- 아래와 같은 Request 헤더만 존재하는 경우
- Accept = 서버에게 자원을 요청한 클라이언트가 이해가능한 컨텐츠 타입이 무엇인지 알려준다.
- Accept-Language = 어떤 언어를 클라이언트가 이해할 수 있는지와 지역 설정 중 어떤것이 선호되는지 알려준다. ( 자연언어를 의미함, 프로그래밍 언어를 의미하지않음 )
- Content-Language = 컨텐츠가 어떤 청중을 위한 언어인지를 설명한다. 명시되어 있지 않으면 모든청중이라고 간주한다.(..??)
- Content-Type = 해당 헤더는 아래 값들만 허용된다.
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
- 요청에 ReadableStream 객체가 사용되지 않는 경우
단순요청은 클라이언트가 헤더에 Origin에 대한 정보를 담아 요청을 보내면, 서버에서 Access-Control-Allow-Origin 헤더에 접근이 허용될 Origin에 정보를 담아 응답하고, 브라우저가 요청한 Origin과 허용된 Origin의 비교를 통해 요청한 응답을 제공하는 방식이다.
출처(https://developer.mozilla.org/ko/docs/Web/HTTP/CORS)
2.프리플라이트(preflight) 요청
프리플라이트 요청이란 단순요청과는 다르게, 먼저 OPTIONS 메소드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 미리 확인한다. Cross-Site로의 요청은 유저 데이터에 영향을 줄 수도 있기 때문에 이와깉이 미리 전송하는것이다.
프리플라이트 요청을 위해서는 위에 단순 요청이 되기위한 조건에 위배가 되어야하는데, Content-Type이 application/xml로 설정한다고 가정하면 해당 요청은 프리플라이트 처리된다.
출처(https://developer.mozilla.org/ko/docs/Web/HTTP/CORS)
3.인증정보를 포함한(Credentialed) 요청
Credential requests는 HTTP Cookies와 HTTP Authentication 정보를 인식한다. 기본적으로 Cross-site에 대한 XMLHttpRequest 혹은 FetchAPI 요청에서 브라우저는 자격증명에 대한 정보를 보내지 않기 때문에, 특정한 플래그를 설정해주어야한다.
const xhr = new XMLHttpRequest(); xhr.withCredentials = true;
위와 같은 요청을 했을 경우, 서버에서는 Control-Allow-Crendentials 헤더에 true를 담아 응답해야 하고, 그렇지 않을경우 브라우저에서는 해당 응답을 거부한다.
API(Application Programming Interface)
응용 프로그램에서 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
프로그램 간에 연결을 시켜주는 다리라고 생각하면 쉽다.
특징
- uri 를 통해 데이터를 받는 형태가 많음
- 구현과 독립적으로 사양(사용법)만 정의되어 있다
- API에 따라 접근 권한이 필요할 수 있다.
- ex) Kakao Map API, java API, 여러 기업들의 오픈 API
어떤 기능이 필요할 때 API를 찾아서 사용한다.
Library
단어 뜻 그대로 도서관으로 생각해보면 쉽다. 필요한 책이 있으면 대여하기 위해 도서관에서 빌려오는 것처럼, 응용 프로그램 개발을 위해 필요한 기능을 가져다쓰는 소프트웨어
특징
- 독립성을 가진다. 다른 라이브러리를 의존하지 않는다.
- 응용 프로그램이 능동적으로 라이브러리를 사용한다. 다시 말해서 개발자가 개발할 때 필요한 부분에 능동적으로 라이브러리를 호출해서 사용한다.
- ex) Lombok, jQuery
Framework
응용 프로그램이나 소프트웨어의 솔루션 개발을 수월하게 하기 위해 제공된 소프트웨어 환경. 단어 뜻 그대로 틀 안에서 일을 한다고 생각하면 쉽다.
Spring Framework를 사용한다면 -> 컨트롤러 생성, 컨트롤러에 비즈니스 로직 작성,
Framework 없이 was를 만들어 사용한다면 -> Socket, InuputStream, OutputStream, Request, 컨트롤러 맵핑, 컨트롤러 생성, 비즈니스 로직 작성
Framework가 없으면 처리해야할 로직이 엄청나게 많다. Spring Framework 덕분에 개발자는 비즈니스 로직에 집중할 수 있었던 것이다.
특징
- 상호협력하는 클래스와 인터페이스의 집합
- 응용 프로그램이 수동적으로 프레임워크에 의해 사용된다.
- Junit, Spring Frameowrk
정리
개발자가 라이브러리를 호출하는 코드를 작성함으로써 라이브러리를 사용했었다면 프레임워크는 프레임워크가 처리할 거 하면서 중간중간에 개발자가 작성한 코드를 호출함으로써 프레임워크라는 틀 안에서 개발자가 작성한 코드를 사용하는 것.
즉 다시 말해서 내가 만든 응용 프로그램이 수동적으로 사용되느냐, 능동적으로 사용하느냐에 라이브러리와 프레임워크 차이점이 있는 것
마지막으로 정리하자면
- Library와 API 차이점은 구현 로직의 유뮤이다.
- Library와 Framework의 차이점은 응용 프로그램의 흐름 주도권을 누가 가지고 있냐의 차이
좋아요1
공유하기
글 요소
출처: https://dundung.tistory.com/279 [DunDung]
