IT 용어

반응형

SOP(동일 출처 정책(Same-Origin Policy))

 

개념


개념을 알기전 먼저 ajax 다른 도메인서버의 자원을 요청 할 경우 이와 같은 에러를 만나게 된다.

(다른 페이지가 아니라 다른 도메인입니다 도메인 www.a.com 자원요청 -> www.b.com)

 

chrome(크롬)

No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin ‘www.b.com' is therefore not allowed access.

 

 FireFox(파이어폭스)

교차 원본 요청 차단: 동일 출처 정책으로 인해 'www.b.com'에 있는 원격 자원을 읽을 수 없습니다. 
자원을 같은 도메인으로 이동시키거나 CORS를 활성화하여 해결할 수 있습니다.

 

외부로 요청이 안 되는 것은 자바스크립트 엔진 표준 스펙에 동일 출처 정책(same-origin policy)이라는 보안 규칙이 존재하기 때문이다.

 

자바스크립트 엔진 표준 스펙? 그럼 <script></script> 안에 있는 것말고

 

다른 도메인 서버의 <img> 파일이나 css 파일을 가져 올 있는 것인가?

정답은 맞습니다

<script></script> 안에 스크립트로 둘러 쌓인걸 "Cross-Site HTTP Requests" 라고 한다.

 

바로 그것이 자바스크립트 엔진 표준스펙에 존재하는 뭐다?

동일 출처 정책(same-origin policy)

 

우리에겐 아주 못된 악역이지만 역시 탄생 배경이 존재합니다.

 

 

사용 이유


예를 들어 정책이 없다는 것은? 그냥 아무나,누구나 도메인 서버에 와서 자원을 가져 갈 있는 것이다. 그렇다는건 비밀번호를 가로채는 스크립트를 만들어 자원을 쉽게 있다는 뜻이 된다.

 

한마디로 보안에 취약하다.

 

 

조건


프로토콜, 호스트명, 포트가같아야만 자원을 주고 받을 있다.

www.a.com -> www.a.com/a1 O

www.a.com/a1 -> www.a.com/a2 O



www.a.com -> www.b.com X

www.a.com/a1 -> www.b.com X

 

하지만 우리는 ajax 이용한 rest api 서비스를 굉장히 많이 사용하기 때문에

same-origin policy 부시고 CORS 허용 해줘야한다.


CORS(교차 출처 자원 공유(Cross Origin Resource Sharing))

 

개념


웹 브라우저에서 외부 도메인 서버와 통신하기 위한 방식을 표준화한 스펙이다. 서버와 클라이언트가 정해진 해더를 통해 서로 요청이나 응답에 반응할지 결정하는 방식으로 교차 출처 자원 공유(cross-origin resource sharing)라는 이름으로 표준화가 되었다.

 

한마디로 Cross-Site Http Request를 가능하게 해주는 표준 규약

 

 

종류


Simple Request

Preflight Request

Credential Request

Non-Credential Request

 

 

Simple Request


이는 다음 3가지를 만족해야 합니다.

1. GET, HEAD, POST 중 한 가지 방식을 사용

2. POST일 경우 Content-type이 아래 셋 중 하나를 만족

- application/x-www-form-urlencoded

- multipart/form-data

- text/plain

3. 커스텀 헤더를 전송하지 않아야 함

 

 

Preflight Request


이름에서 볼 수 있는 것처럼 Preflight(예비) 요청을 먼저 보내고 서버가 이에

응답이 가능한 지 확인합니다. 예비 요청은 OPTION메서드로 HTTP 요청을 전송합니다.

 

이후 실제 Actual(본) 요청을 보냅니다.

그리고 서버가 이에 응답하며 통신하는 형태이죠.

Preflight Request는 위의 Simple Request에 해당하는 조건에 만족하면 안돼요.

그렇기에 GET, HEAD, POST 이외 메서드를 사용하는 경우에만 사용 가능한 요청입니다

 

만약 POST 요청을 사용할 경우에는 Content Type이 위의 3가지 경우가 아니거나 

(application/json)

또는 커스텀 헤더를 사용할 경우에 사용할 수 있다는 점을 기억해야 합니다.

예비 요청과 예비 응답, 본 요청과 본 응답 총 4번의 형태로 구성되어 있습니다.

 

순서

Client 예비(method = OPTIONS) 전송-> Server OPTIONS 확인하고 서버쪽 CORS 허용 돼있으면 요청에 답함

(그렇지 않으면 405 Method Not Allowed HTTP 반환)

 

 

Credential


HTTP Cookie와 HTTP Authentication 정보를 인식할 수 있게 해주는 요청

 

요청 시 xhr.withCredentials = true를 지정하는 것이 가장 큰 특징

Access-Control-Allow-Credentials: true

만약 위의 설정이 false라면? 브라우저는 이 요청을 거부할 것입니다.

 

 

Non-Credential


 

사실 withCredentials 플래그는 디폴트 값이 false입니다.

그러니 위의 Credential 요청에서와 같이 처리해주지 않는다면 모든 요청이 바로

 

Non-Credential에 해당된다고 볼 수 있습니다.

 

 

방식


1.jsonp 방식

위에서 설명했듯이 css,img,js 파일은 동일 출처 정책에 걸리지 않는다.

그러므로 <script></script> 스크립트를 json 형식으로 변경 읽어오는 방법

하지만 GET 방식만 요청이 가능하다.

 

2. 웹브라우저 외부 요청 허용 옵션 사용

-disable-web-security 옵션을 추가하여 크롬 실행

 

1,2번은 추천하지 않습니다. 2번은 더더욱

일반 사용자들에게 -disable-web-security 옵션을 써서 브라우저를 실행 시키라고 하는 것은 말도 안되죠

 

3.CORS 요청 핸들링

Access-Control-Allow-Origin: *

Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS

Access-Control-Max-Age: 3600

Access-Control-Allow-Headers: Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization

 

간단 설명


Request headers (클라이언트의 요청 해더)  

Origin: 요청을 보내는 페이지의 출처(도메인) 

Access-Control-Request-Method: 실제 요청하려는 메서드 

Access-Control-Request-Headers: 실제 요청에 포함되어 있는  해더 이름

 

Response headers (서버에서의 응답 해더)

Access-Control-Allow-Origin: 요청을 허용하는 출처. * 이면 모든 곳에 공개되어 있음을 의미한다. 

Access-Control-Allow-Credentials: 클라이언트 요청이 쿠키를 통해서 자격 증명을 해야 하는 경우에 true. true를 응답받은

클라이언트는 실제 요청 시 서버에서 정의된 규격의 인증값이 담긴 쿠키를 같이 보내야 한다.

 

Access-Control-Expose-Headers: 클라이언트 요청에 포함되어도 되는 사용자 정의 해더.

 

Access-Control-Max-Age: 클라이언트에서 preflight의 요청 결과를 저장할 기간을 지정.

클라이언트에서 preflight 요청의 결과를 저장하고 있을 시간이다. 해당 시간 동안은 preflight요청을 다시 하지 않게 된다.

 

Access-Control-Allow-Methods: 요청을 허용하는 메서드. 기본값은 GET, POST라고 보면 된다.

이 해더가 없으면 GET과 POST 요청만 가능하다. 만약 이 해더가 지정이 되어 있으면,

클라이언트에서는 해더 값에 해당하는 메서드일 경우에만 실제 요청을 시도하게 된다.

 

Access-Control-Allow-Headers: 요청을 허용하는 해더.

 

 

조건


Client Access-Control-Allow-Origin 허용 해줘야하고,

Server Access-Control-Allow-Origin 허용 해줘한다

 

한마디로 Client-Server 양쪽 모두 허용해줘야 통신이 가능하다.

 

저는 Client 웹에만 허용을 주구장창하고 API 서버에는 허용을 안했습니다.

그러고 삽질을 엄청했죠 지구의 맨틀까지 보일뻔 보일 뻔했습니다 너무 삽질해서…

 

이런 개념말고 허용해주는 코드를 달라고요??

그건 따로 Java 탭에서 다루겠습니다.

 

반응형
반응형

먼저 IT 일하시는 분들은 엔지니어,개발자 .. 분야에서 Linux 프로그래밍 언어를 다룰

Namespace(이하 네임스페이스)라는 말이 굉장히 많이 나온다.

 

대충 네임스페이스는 "소속"이다. 까지만 알고 넘어가는 경우가 많은데 정확히 알아보도록 하겠습니다.

 

개념


네임스페이스.. 직역해보면 이름공간? 뭔가 이름과 관련된 용어인건 분명하다.

 

그럼 이름은 지어지는가? 바로 구분, 구분를 하려고 이름을 짓지않습니까?

 

블로그 이름은? .java의 개발일기

다른 사람이저에 다른 글을 보더라도 .java의 개발일기라는 이름을 보고

사람 글이구나 싶을껍니다.

 

물론 Linux에서 다루는 네임스페이스와 프로그래밍 언어에서 다루는 네임스페이스는 정확한 뜻이 조금 다를수 있으나,

 

사용하는 목적은 같다 네임스페이스는 한마디로,

 

한 덩어리의 데이터에 이름을 붙여 충돌 가능성을 줄이고, 쉽게 참조할 수 있게 하는 개념

 

예를 들면 A라는 네임스페이스의 자원1,2,3

B라는 네임스페이스의 자원1,2,3

 

여기서 자원 1,2,3 같으나, 네임스페이스로 구분을 있다는 것이죠

 

 

 

연관 키워드


Linux : PID namespace, network namespace, UID namespace…

Programming language : namespace A() {}, namespace B() {}

MyBatis : <mapper namespace="mapper.board-Mapper">

 

 

 

반응형
반응형

프레임 워크(Framework)

 

개념


원하는 기능 구현에만 집중하여 빠르게 개발할 수 있도록 기본적으로 필요한 기능을 갖추고 있는 것

 

프로그램의 기본이 되는 뼈대라고 보면 된다.

뼈대? 뼈대? 이해가 가지 않는다.

 

예를 들면 공룡제작 프레임워크 다운받아서 써보자.

기본으로 공룡 뼈대가 제작돼있다.


-티라노사우루스 뼈대

-벨로키랍토르 뼈대

-스피노사우루스 뼈대

-알로사우루스 뼈대

 

 

그럼 우리가 티라노사우루스 뼈대(프레임워크) 골라 제작(코딩) 한다고 가정했을 ,

티라노의 형태가 이미 만들어져있으니 살을 어떻게 붙일까만 집중해서 코딩할 있겠죠

그리고

뼈대엔 팔이 2 있는데 새로운 뼈를 만들어서 팔을 3 만들 없다.

 

? 2개라고 정의 해놨으니까요 "티라노사우르스 뼈대는 팔이 2개다." 라고 말이죠

하지만? 팔을 굵게 만들고, 꼬리는 짧게 다리는 길게(메소드길게(메서드) 만들순 있습니다.

 

사용 이유


만약 공룡 제작 프레임워크가 없다면

뼈대 자체를 만드는데만 세월이 걸리게 됩니다.

 

하지만 프레임워크를 이용한다면 더욱 빠르게 만들 있고,

2 다리 2 꼬리 1 이렇게 정해져있으니 표준을 정할 있습니다.

예를 들어

공룡 제작프레임워크 소스를 받는다면 " 2 다리 2 꼬리 1개이겠구나" 있습니다.

 

언어별 대표 프레임워크


Java - Spring

Python - Django

PHP - Laravel

JavaScript - React

GO - Revel

Ruby - Rails

 

라이브 러리(Library)

 

개념


필요한 기능을 미리 준비 해놓은 개념

 

굉장히 범위가 포괄적이다.

미리 작성된 코드서브루틴(함수), 클래스자료형 

모두가 라이브러리에 속한다.

 

한마디로 재사용이 가능한 코드의 집합 이라고 보시면 됩니다.

 

예를 들면 예시처럼 공룡 제작 프레임워크를 쓰고 있다가

 

그냥 발톱이 아닌 강철 발톱 쓰고 싶다면?

발톱은 2 다리 2

4개나 들어간다.

 

그럼 라이브러리를 쓰지 않는다면 강철 발톱을 하나 만들어서

일일이 복사 붙여넣기 해야 한다.

 

매우 가독성이 떨어지며 유지보수도 굉장히 힘들다.

하지만 이미 만들어진 강철 발톱라이브러리 있다면 라이브러리를 적용 시킴으로써

바로 강철 발톱 장착 시킬 있다.

 

여기서 프레임워크의 강점이 또 나온다. 강철 발톱은 반드시 공룡 제작 프레임워크에만 사용 가능하다는 점.

(특정 프레임워크에 맞게 나온 라이브러리들이 많이 존재한다)

 

사용 이유


재사용이 필요한 기능으로 반복적인 코드 작성을 없앨 있다.

그러므로 개발이 훨씬 수월해진다.

 

 

대표 라이브러리


JavaScript - jQuery, Chart.js

Python - 아파치 Libcloud, Arrow,Behold

Java - JUnit, Jackson

반응형
반응형

정적 언어

 

 

개념


자료형(Type)이 고정돼 있는 언어.

정적 언어는 *컴파일 진행할 변수의 타입이 결정된다.

 

*컴파일 : 우리 사용한 언어를 컴퓨터가 알아먹을  있게 바이트코드 라는 것으로 변경하는 작업

 

대표적인 예를 들자면,

Java(자바)

String a = 10; //에러

int b = 10; //성공

var c = 22; //에러

이렇게 코딩을 했을 경우 바로 빨간줄이 그어지면서 에러가 나는데,

 

유치한 상황극

Java : " String인데 정수잖아, 그리고 var 뉘집 개야? 몰라 에러 나는 코드야 컴파일 안해줘 아니 못해줘"

프로 야근러 : " 그러네 미안"

 

이런 식으로컴파일 시에 자료형에 맞지 않은 값이 들어있으면 컴파일 에러가 발생합니다.

 

 

사용 이유


컴파일 시에 타입에 대한 정보를 결정하기 때문에 속도 향상

타입 에러로 인한 문제점을 초기에 발견할 있어 타입의 안정성 보장

 

 

종류


C

C#

C++

Java

Go

Haskell

Kotlin

Rust

Scala 

... 외에 더 있습니다.

 

 

동적 언어

 

개념


자료형이 그것을 처리할 함수(또는 메서드)에 따라 그때그때 바뀌는 언어.

동적 타입 언어의 자료형은 컴파일 시 자료형을 정하는 것이 아니고 *런타임 시에 결정합니다.

대표적인 예를 들자면,

JavaScript(자바스크립트)

function sum(){
var a = 10;
var b= "10";
console.log(a+b);
//"1010" 
}

이런 식으로 정수 10인 a 변수와 문자열 "10"인 b 변수를 더하면 에러를 뱉지 않고, 문자열 "1010"이 된다.

 

유치한 상황극 2

JavaScript : "a랑 b를 더한다고? 음 정수+문자열이긴 한데 정수 값으로 된 문자열이니까 내가 합쳐줘야겠다 여기 1010"

프로 야근러 : "고맙다^^ 근데 내가 원하는 값은 20이야"

 

*런타임 : 프로그래밍 언어가 구동되는 환경


런타임이 실행될 때 타입을 검사한다는 게 무슨 말일까?

JavaScript(자바스크립트) 코드로 알아보자

function calc(){
var a = 'blueHat'-1;
return a;
}

Java 코드였다면 미치고 팔짝 뛰면서 에러를 뱉을 텐데

JavaScript는 아무런 반응이 없다. 컴파일을 통과했다는 소리!

하지만

calc();

함수를 실행한다면? 실행될 때 즉!! *런타임 될 때!!

NaN (TypeError)를 뱉습니다.

 

JavaScript : 이건 너무한 거 아니냐고! 퉤 TypeError

 

 

사용 이유


*런타임(Run time)까지 타입에 대한 결정을 끌고 갈 수 있기 때문에 많은 선택의 여지가 있고,

동적으로 변경되기 때문에 결과가 이상하게 나올지라도 (빨간 글씨만 나오면 심장이 두근대는)

매우 까다로운(?) 자료형 검사를 피할 수 있다.

 

 

종류


JavaScript

Ruby

Python

SmallTalk

Lisp

Lua

Perl

PHP

... 외에 더 있습니다. 

 

 

 

반응형
반응형

JSON(JavaScript Object Notation)

 

개념


경량(Lightweight)의 DATA-교환 형식이다.

 

경량(Lightweight)의 DATA-교환 형식~

경량(Lightweight)의 DATA-교환 형식~~!!

 

속성- || - 으로 이루어진 데이터 오브젝트를 전달하기 위해

인간이 읽을 있는 텍스트를 사용하는 *개방형 표준 포맷.

포맷이랍니다. 포맷

 

JSON이라는게 대단한게 아니고 프로그래밍 언어도 아니고

 

그냥 데이터 주고 받을 트래픽을 최소화하기 위한

데이터가 들어있는 가벼운 종이 같은 개념으로 보시면 됩니다.

 

시작은 JavaScript로부터 파생됐지만(그래서 JavaScript 문법) 언어 독립형 포맷이다.

수년 지배 해왔던 XML 대체 있는 아주 매우 완전 주요 데이터 포맷

 

보통 ajax rest api에서 XML , JSON 형식으로 많이 받죠

쓰이는 JSON JSON 맞습니다.

 

프로그래밍 언어의 제약이 거의 없습니다

C,JAVA,Rudy 등 거의 모든 언어에서 사용 가능합니다.

 

공식 미디어 타입(MIME 타입) : application/json

파일 확장자 : .json

 

*개방형 표준 : 문서가 공개되어있는 표준 , 사용이 자유로움 , 로열티를 지불할 필요 없음

 

문법 종류


수(Number) : number는 8진수와 16진수 형식을 사용하지 않는것을 제외하면 C와 Java number 처럼 매우 많이 비슷하다.

 

문자열(String): 0개 이상의 유니코드 문자들의 연속. 문자열은 큰 따옴표(")로 구분하며 역슬래시 이스케이프 문법을 지원한다.

 

참/거짓(Boolean): true 또는 false 

 

배열(Array): 0 이상의 임의의 종류의 값으로 이루어진 순서가 있는 리스트. 대괄호로 나타내며 요소는 쉼표로 구분한다.

 

객체(Object): 순서가 없는 이름/값 쌍의 집합으로, 이름(키)이 문자열이다.

 

null: 빈 값으로, null을 사용한다.

 

사용 이유


JSON 표현식은 사람과 기계 모두 이해하기 쉬우며 용량이 작아서, 최근에는 JSON이 XML을 대체해서 데이터 전송 등에 많이 사용

 

특정 언어에 종속되지 않으며, 대부분의 프로그래밍 언어에서 JSON 포맷의 데이터를 핸들링 할 수 있는 라이브러리를 제공

 

제일 중요한 사용 이유는 데이터를 전송할 최소한의 용량으로 전송하기 위함.

 

ajax rest api 통신 자주 받는 데이터 형식인 만큼 필수적으로 알아야 합니다.

반드시 개념을 숙지하시길 바랍니다.

문법이 없는 이유는 Java JavaScript 나눠서 올릴 예정입니다.

 

 

 

정리

1.DATA 교환하는 형식 그대로 DATA 주고 받을 , 편지를 주고 받을

보통 종이를 쓰는거 처럼 DATA 받을땐 JSON 형식

2.JSON 쓰는데 프로그래밍 언어의 제약이 거의 없다. C,Java,Rudy... 여러 종류 가능

2.공식 미디어 타입(MIME 타입) application/json이다

 

 

설명이 미흡하다고 느끼신 분들은

JSON 공식 홈페이지 참조 http://www.json.org/json-ko.html

반응형
반응형

우리를 괴롭히지만 백엔드 개발자라면 반드시 마주해야 하는

REST와 REST API와 RESTful의 개념을 확실히 알아보자.

 

REST (Representational State Transfer)

 

개념


하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념이다.

 

하나의 URI는 하나의 고유한 리소스를 대표하도록 설계!

 

자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다.

 

기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에,

웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

 

HTTP 통신을 한다는 말.

 

REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다 통신 방식이랍니다. 통신 방식

 

 

TMI


2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.

 

 

사용 이유


HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.

웹 서버+소프트 웨어(설치)가 아니라 웹 서버+REST API가 된다는 말.

 

HTTP 표준 프로토콜이기 때문에 HTTP 통신만 되는 플랫폼이라면

플랫폼의 영향을 받지 않는다.

 

REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.

 

서버와 클라이언트의 명확한 역할 분리.

 

다양한 브라우저 및 모바일 디바이스에서 통신 가능.

 

애플리케이션 분리 및 통합 가능.

 

 

종류


METHOD

역할

POST(Create)

POST를 통해 해당 URI를 요청하면 리소스를 생성합니다.

GET(Read)

GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.

PUT(Update)

PUT를 통해 해당 리소스를 수정합니다.

DELETE(Delete)

DELETE를 통해 리소스를 삭제합니다.

HEAD

Header 정보를 조회(HEAD) 합니다.

 

종류는 무조건 외우는 걸로!

 

 

특징


1.Server-Client(서버-클라이언트 구조)

 

자원 요청(Request) Client

-사용자 인증, 세션, 로그인,토큰 정보 등을 관리

 

자원 응답(Response) Server

-API 제공 , 비즈니스 로직 처리 및 저장

 

1-1.Stateless(무상태)

 

HTTP 프로토콜은 *Stateless Protocol이므로

REST 역시 무상태성을 갖는다. (HTTP 프로토콜이니까)

 

*Stateless Protocol (무상태 프로토콜)

 

- 서버와 클라이언트의 이전 통신 상태 (state)를 저장하지 않는 프로토콜  

  - 서버의 현재 상태에 따라 요청 (request)에 대한 응답(response)이 달라질 수 있음

  - 연속된 상태정보를상태 정보를 저장하지 않기 때문에 HTTP는 application 구현 상에서 상태 정보를 저장해야 함 

 

1-2.Client의 context를 Server에 저장하지 않는다.

(그러므로 할 일이 줄어듬 구현이 단순해짐)

 

1-3.Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리.

(이 부분은 Stateless Protocol 설명에 나와있다.)


 

2.Cacheable(캐시 처리 가능)

 

2-1. 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.

-HTTP 캐싱 기능 적용 가능

-HTTP 프로토콜 표준 *Last-Modified 태그나 *E-Tag 이용 캐싱 구현 가능

-대량의 요청을 캐시 사용에 의해 응답 시간 ↑ 성능 ↑ 서버 자원 이용률 ↑ REST Server 트랜잭션 발생 X

동일한 GET 메서드 실행 -> 캐시에서 가져옴 -> 속도 향상

 

*Last-Modified

응답은 HTTP 헤더에 서버가 알고 있는 가장 마지막 수정된 날짜와 시각을 담고 있습니다. 

이미지/CSS/JS와 같은 정적 파일들은 아파치에서 자동적으로 Last-Modified, If-Modified-Since 헤더를 붙여줌

문법

Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

 

*E-Tag

HTTP 응답 헤더는 특정 버전의 리소스를 식별하는 식별자입니다. 웹 서버가 내용을 확인하고 변하지 않았으면, 웹 서버로 full 요청을 보내지 않기 때문에, 캐시가 더 효율적이게 되고, 대역폭도 아낄 수 있습니다. 하나, 만약 내용이 변경되었다면, "mid-air collions"이라는 리소스 간의 동시 다발적 수정 및 덮어쓰기 현상을 막는데 유용하게 사용됩니다.

 

아파치에서는 이미지/CSS/JS와 같은 정적 파일은 자동으로 ETag 헤더를 붙여줌

 

같은 내용을 보냈으면 캐시로 있던 거 보내고 아니면 데이터 업데이트해준다는 말.


3.Layered System(계층화)

 

3-1.Client는 REST API Server만 호출.

3-2.REST Server는 다중 계층으로 구성될 수 있다.

3-3.API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.

또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상할 수 있다.

PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.


4.Uniform Interface(인터페이스 일관성)

 

URI로 지정한 Resource에 대한 조작(CRUD)을 통일되고 한정적인 인터페이스로 수행.

HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능.

특정 언어나 기술에 종속 X.

 

 

이제 REST 설명 끝났고…………………….

 

REST API

 

개념


위 내용에서 실컷 설명한 { REST } 기반으로 서비스 API를 구현한 것!

 

 

사용 이유


사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.

REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.

 

계속 반복되는 말

REST는 HTTP 표준 기반 HTTP가 사용되는 데는 모두 다 사용할 수 있다.

 

 

설계 규칙


도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념, 단수 명사를 사용.

컬렉션 : 서버에서 관리하는 디렉터리라는 리소스, 복수 명사를 사용.

스토어 : 클라이언트에서 관리하는 리소스 저장소, 복수 명사를 사용.

 

URI는 정보의 자원을 표현해야 한다.

 

Resource

 

동사보다는 명사, 대문자보다는 소문자를 사용.

GET /Member/1 -> GET /members/1

 

자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.

 

URI에 HTTP Method가 들어가면 안 된다.

GET /members/delete/1 -> DELETE /members/1

URI에 행위에 대한 동사 표현이 들어가면 안 된다.(즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)

GET /members/show/1 -> GET /members/1
GET /members/insert/2 -> POST /members/2

경로 부분 중 변하는 부분은 유일한 값으로 대체한다.(즉, :id는 하나의 특정 resource를 나타내는 고윳값이다.)

student를 생성하는 route: POST /students
id=12인 student를 삭제하는 route: DELETE /students/12

 

슬래시 구분자(/ )는 계층 관계를 나타내는 데 사용한다.

http://restapi.example.com/houses/apartments

URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.

http://restapi.example.com/houses/apartments/ (X)

 

하이픈(- )은 URI 가독성을 높이는 데 사용

불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.

 

밑줄(_ )은 URI에 사용하지 않는다.

밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.

 

파일 확장자는 URI에 포함하지 않는다.

REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.

Accept header를 사용한다.

http://restapi.example.com/members/soccer/345/photo.jpg (X)
GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)

리소스 간에는 연관 관계가 있는 경우

/리소스명/리소스 ID/관계가 있는 다른 리소스명

GET : /users/{userid}/devices

 

RESTful

 

개념


RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.

 

REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다.

 

RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.

즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다

 

이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

 

서드 파티 웹 콘텐츠를 만드는 경우, 그들에게 제공해줄 수 있을 만큼의 REST API를 제공하는 것.


정리

 

REST

1. 로이 필딩이라는 사람이 2000년에 발표함.

2. 하나의 URI 하나의 고유한 리소스를 대표하도록 설계한 개념

3.HTTP 프로토콜을 사용하는 곳이면 사용 가능

4.Server-Client 명 확 히 구분됨

5. 종류는 GET, POST, PUT, DELETE가 있음.


REST API

1.REST 기반으로 만들어진 API

2.URI는 정보의 자원을 표현해야 한다.

3. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.


RESTful

1. 여긴 REST API 제공합니까? 네.라고 할 수 있다면 RESTful

 

다음엔 개념 말고 실제 문법과 사용법에 대해 포스팅하겠습니다.

반응형
반응형

Web Server

 

개념


클라이언트가 서버에 페이지 요청을 하면 요청을 받아 정적 콘텐츠(. html,. png,. css 등)를 제공하는 서버

 

정적 컨텐츠를 제공하는 서버!

 

HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스하는 기능을 담당

 

1. 정적인 콘텐츠 제공

WAS를 거치지 않고 바로 자원을 제공한다.(. html. jpeg. css)

 

2. 동적인 콘텐츠 제공을 위한 요청 전달

클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.

 

클라이언트는 일반적으로 웹 브라우저(크롬, IE, FireFox 등)를 의미

 

 

사용 이유


누군가 이런 말을 한다. 요즘 WAS만 설치하면 웹 서버 기능도 다 하던데? 굳이 필요 있나?

그 이유를 설명합니다.

 

1. 서버 부하 방지

 

이미지 파일이 클라이언트에게 가는 과정

1-1. 클라이언트 접속 (www.naver.com)

1-2.HTML 문서 받음

1-3. 필요한 이미지 파일, JS 파일 받음

 

Web Server를 통해 정적인 파일들을 WAS까지 가지 않고 앞단에서 빠르게 보내줄 수 있다.

따라서 Web Server에서는 정적 콘텐츠만 처리하도록 기능을 분배하여

 

서버의 부담을 줄일 수 있다!!

 

2. 보안 강화

 

SSL에 대한 암호화, 복호화 처리에 Web Server를 사용!

 

3. 로드 밸런싱 ( Load Balancing )

 

fail over(장애 극복), fail back 처리에 유리

특히 대용량 웹 애플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.

예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.

 

Load Balancing을 위해서 Web Server를 사용!

 

예시

WAS1 과부하 CPU 80% 이상

WAS2로 부하 분산

 

대표 Web Server 종류

Apache Server
Nginx
MS IIS

 

 

WAS(Web Application Server)

 

개념


동적 콘텐츠를 제공하기 위해 만들어진 애플리케이션 서버 (DB 조회, 로직 처리가 요구되는 콘텐츠)

 

동적 콘텐츠를 제공하는 서버!

 

“웹 컨테이너(Web Container)” 혹은 “서블릿 컨테이너(Servlet Container)”라고도 불린다

Container란 JSP, Servlet을 실행시킬 수 있는 소프트웨어를 말한다.

즉, WAS는 JSP, Servlet 구동 환경을 제공한다.

 

WAS는 JSP, Servlet 구동 환경을 제공!

 

 

사용 이유


WAS = Web Server + Web Container

Web Server 기능들을 구조적으로 분리하여 처리하고자 하는 목적으로 제시되었다.

분산 트랜잭션, 보안, 메시징, 스레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.

주로 DB 서버와 같이 수행된다.

현재는 WAS가 가지고 있는 Web Server도 정적인 콘텐츠를 처리하는 데 있어서 성능상 큰 차이가 없다.

 

1. 프로그램 실행 환경과 DB 접속 기능 제공

2. 여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능

3. 업무를 처리하는 비즈니스 로직 수행

 

대표적 WAS 종류

Apache Tomcat
WildFly Jboss
TmaxSoft Jeus
IBM Web Sphere

Web Server와 WAS 차이 정리

Web Server : 정적

WAS : 동적

 

Web Server와 WAS를 따로 두는 이유 정리

1. 서버부하 방지

2. 하나의서버 혼용 Application (java, php.. 등)사용 가능

3. 로드밸런싱

즉, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리한다.

 

명칭


1. 하나의 서버에 WEB,WAS, DB 설치 : single-Tier

2.WEB 서버 , WAS,DB 서버 : 2-Tier

3.WEB 서버 , WAS 서버 , DB 서버 : 3-Tier


[WAS] Cent 7 서버 구축해보기!

https://java119.tistory.com/8?category=811335

 

 

 

 

 

 

반응형

[ISO] ISO 8601 개념

2019. 10. 24. 12:32
반응형

ISO 날짜 형식이란?
정식 명칭 
Date elements and interchange formats - Information interchange - Representation of dates and times
미쳤다..
현재 제일 최신 버전 ISO 8601
구버전 ISO 8601:2000, ISO 8601:1988 
날짜와 시간과 관련된 데이터 교환을 다루는 국제 표준이다. 
데이터 교환을 다루는 국제 표준
데이터 교환을 다루는 국제 표준
데이터 교환을 다루는 국제 표준
3번 강조
이 표준은 국제 표준화 기구(ISO)에 의해 공포되었으며 1988년에 처음으로 공개

목적
날짜와 시간의 숫자 표현에 대한 오해를 줄이고자 함에 있는데, 숫자로 된 날짜와 시간 작성에 있어 다른 관례를 가진 나라들 간의 데이터가 오갈 때 특히 그렇다.
필자 필수 검색어 : java || javascript UTC to KST / KST to UTC 

형태
가장 기본적인 형식(날짜와 시간)은 아래와 같습니다.
2017-03-16T17:40:00+09:00
• 날짜 : 년-월-일의 형태로 나와있습니다.
• T : 날짜 뒤에 시간이 오는것을 표시해주는 문자입니다.
• 시간 : 시:분:초의 형태로 나와있으며 프로그래밍 언어에 따라서 초 뒤에 소수점 형태로 milliseconds가 표시되기도 합니다.
• Timezone Offset : 시간 뒤에 ±시간:분의 형태로 나와있으며 UTC기준 시로부터 얼마만큼 차이가 있는지를 나타냅니다. 현재 위의 예시는 한국시간을 나타내며 UTC기준 시로부터 9시간 +된 시간임을 나타냅니다
• Z or +00:00 : UTC기준시를 나타내는 표시이며 “+00:00”으로 나타내기도 합니다.


표기법

연월일 표기법
1981-02-22 또는 19810222는 1981년 2월 22일을 나타낸다.

연과 연중일수 표기법
YYYY-DDD(확장 형식) 또는 YYYYDDD(기본 형식)로 표기한다. DDD는 연중 날의 번호로서 1월 1일이 001이며, 12월 31일은 평년은 365, 윤년은 366이 된다.
1981-053 또는 1981053 : 1981년의 53번째 날, 즉 2월 22일을 나타낸다.

시간 표기법
시간의 표기에는 쌍점을 쓴 hh:mm:ss(확장 형식) 또는 hhmmss(기본 형식)를 사용한다. hh는 시(時)로서 00부터 24까지의 값을 갖는다. mm은 분(分)으로서 00부터 59까지의 값을 갖는다. ss는 초(秒)로서 00부터 59까지의 값을 갖는다. 반점이나 온점을 써서 앞 단위를 나눈 시간을 나타낼 수도 있는데, 이때 십진수를 사용하며 자릿수는 정보 교환 주체 사이에 미리 합의해야 한다. 다음은 분절 시간 표현 자릿수로 한 자리를 정한 예이다.
10:20:30,4 또는 102030,4 : 10시 20분 30.4초
10:30,5 또는 1030,5 : 10:30:30과 같다.
10.5 : 10:30와 같다.

날짜와 함께 표기할 때 표기법
날짜와 시간 사이에 T를 넣어 표기한다.
1981-02-22T 09:00:00 : 1981년 2월 22일 09:00

기간 표기법
기간을 나타낼 때에는 시작일시/종료일시로 표기한다.
1981-02-22/2007-09-26 : 1981년 2월 22일 ~ 2007년 9월 26일
1981-02-22T 09:00:00+09:00/2007-09-26T 17:00:00+09:00 : UTC+9 시간대에서 1981년 2월 22일 9시 ~ 2007년 9월 26일 17시

시간대의 표기법
시간대를 표기할 때에는 Z또는 +/- 기호를 사용한다.
Z 또는 +/- 기호를 사용  
Z 또는 +/- 기호를 사용
UTC 시간대에서는 시각 뒤에 Z를 붙인다.
예) 1981-02-22T 09:00Z 또는 19810222 T0900 Z : UTC 시간대에서의 1981년 2월 22일 오전 9시
UTC 외의 시간대에서는 시각 뒤에 +- hh:mm, +- hhmm, +- hh를 덧붙여 쓴다.
예) 1981-02-22T09:00:00+09:00 : UTC+9 시간대에서의 1981년 2월 22일 오전 9시
+가 붙으면, UTC의 시각보다 더 "빠르다"다는 의미다. 반대로 -는 느리다는 것을 의미하다.
예를 들어, 1981-02-22T09:00+09:00 는 1981-02-22T 00:00Z 와 동일하다.
즉, UTC+9 시간대에서는 오전 9시이지만, UTC 시간대에서는 오전 0시이다.

정리
1.날짜와 시간과 관련된 데이터 교환을 다루는 국제 표준이다. 
2. 저 위에 표기법과 일치하거나 T가 붙으면 ISO 형식의 시간이다.
3.Z가 붙으면 UTC 시간대이다.
4. 현재 최신 버전은 ISO 8601이다.

반응형

+ Recent posts