PhantomJS란?

헤드리스 브라우저로 요즘 유명한 브라우저

Headless browser란?

헤들리스 브라우저는 그래픽 유저 인터페이스가 없는 웹브라우저를 뜻합니다. 헤들리스 브라우저는 웹 브라우저와 유사한 환경을 가졌지만 커맨드 라인 인터페이스를 통해 실행하고 제어할 수 있는 브라우저들을 말합니다. 헤들리스 브라우저엔 자바로 작성된 HtmlUnit이라는 것도 많이 사용됐었습니다.

사용용도

PhantomJS와 같은 헤들리스 브라우저는 아래와 같은 용도로 사용됩니다.

Jasmine, QUnit, Mocha와 같은 테스트 프레임워크에서 함수를 테스트 할 때 사용

웹사이트의 스크린샷, 썸네일 프리뷰 등을 만들 때 사용. SVG, Canvas를 포함한 웹 컨텐츠도 캡쳐가 됨

DOM api, jQuery와 같은 라이브러리로 웹 페이지를 조작할 때 사용

HAR 파일을 만들어 웹 페이지의 성능 측정을 할 때 사용. Jenkins나 YSlow를 통해 자동화 할 수도 있음.

DDOS 공격

광고 노출횟수 늘리기


설치

http://phantomjs.org/download.html

예제

http://phantomjs.org/examples/index.html

'' 카테고리의 다른 글

Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20

개요

HTTP 요청은 기본적으로 Cross-Site HTTP Requests가 가능합니다. 다시 말하면, <img> 태그로 다른 도메인의 이미지 파일을 가져오거나, <link> 태그로 다른 도메인의 CSS를 가져오거나, <script> 태그로 다른 도메인의 JavaScript 라이브러리를 가져오는 것이 모두 가능합니다. 하지만 <script></script>로 둘러싸여 있는 스크립트에서 생성된 Cross-Site HTTP Requests는 Same Origin Policy를 적용 받기 때문에 Cross-Site HTTP Requests가 불가능합니다. 즉, 프로토콜호스트명포트가 같아야만 요청이 가능합니다.

AJAX가 널리 사용되면서 <script></script>로 둘러싸여 있는 스크립트에서 생성되는 XMLHttpRequest에 대해서도 Cross-Site HTTP Requests가 가능해야 한다는 요구가 늘어나자 W3C에서 CORS라는 이름의 권고안이 나오게 되었습니다.

CORS 요청의 종류

CORS 요청은 Simple/Preflight, Credential/Non-Credential의 조합으로 4가지가 존재합니다. 브라우저가 요청 내용을 분석하여 4가지 방식 중 해당하는 방식으로 서버에 요청을 날리므로, 프로그래머가 목적에 맞는 방식을 선택하고 그 조건에 맞게 코딩해야 합니다.

Simple Request

아래의 3가지 조건을 모두 만족하면 Simple Request

  • GET, HEAD, POST 중의 한 가지 방식을 사용해야함.
  • POST 방식일 경우 Content-type이 아래 셋 중의 하나여야함.
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain
  • 커스텀 헤더를 전송하지 말아야함.

Simple Request는 서버에 1번 요청하고, 서버도 1번 회신하는 것으로 처리가 종료됩니다.

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]

Preflight Request

Simple Request 조건에 해당하지 않으면 브라우저는 Preflight Request 방식으로 요청합니다.따라서, Preflight Request는 GET, HEAD, POST 외의 다른 방식으로도 요청을 보낼 수 있고, application/xml 처럼 다른 Content-type으로 요청을 보낼 수도 있으며, 커스텀 헤더도 사용할 수 있습니다.

이름에서 짐작할 수 있듯, Preflight Request는 예비 요청과 본 요청으로 나뉘어 전송됩니다. 먼저 서버에 예비 요청(Preflight Request)를 보내고 서버는 예비 요청에 대해 응답하고, 그 다음에 본 요청(Actual Request)을 서버에 보내고, 서버도 본 요청에 응답합니다.

하지만, 예비 요청과 본 요청에 대한 서버단의 응답을 프로그래머가 프로그램 내에서 구분하여 처리하는 것은 아닙니다. 프로그래머가 Access-Control- 계열의 Response Header만 적절히 정해주면, OPTIONS 요청으로 오는 예비 요청과 GET, POST, HEAD, PUT, DELETE 등으로 오는 본 요청의 처리는 서버가 알아서 처리합니다.

아래는 Preflight Requests로 오가는 HEADER를 보여줍니다.

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

Request with Credential

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

요청 시 xhr.withCredentials = true를 지정해서 Credential 요청을 보낼 수 있고, 서버는 Response Header에 반드시 Access-Control-Allow-Credentials: true를 포함해야 하고, Access-Control-Allow-Origin 헤더의 값에는 *가 오면 안되고 http://foo.origin과 같은 구체적인 도메인이 와야 합니다. 만약 Credentials 옵션은 true로 줬는데 Access-Control-Allow-Origin의 값을 *로 주면 에러가 발생합니다.

Request without Credential

CORS 요청은 기본적으로 Non-Credential 요청이므로, xhr.withCredentials = true를 지정하지 않으면 Non-Credential 요청입니다.

CORS 관련 HTTP Response Headers

서버에서 CORS 요청을 처리할 때 지정하는 헤더

Access-Control-Allow-Origin

Access-Control-Allow-Origin 헤더의 값으로 지정된 도메인으로부터의 요청만 서버의 리소스에 접근할 수 있게 합니다.

Response Header

Access-Control-Allow-Origin: <origin> | *

<origin>에는 요청 도메인의 URI를 지정합니다. 모든 도메인으로부터의 서버 리소스 접근을 허용하려면 *를 지정합니다. Request with Credential의 경우에는 *를 사용할 수 없습니다. 또한 보통 Access-Control-Allow-Origin 옵션은 1개의 도메인만 작성할 수 있게 되어 있습니다. 만약 1개 이상의 도메인을 적으면 에러를 발생합니다. (해결방안은 스크립트로..)

Access-Control-Expose-Headers

기본적으로 브라우저에게 노출이 되지 않지만, 브라우저 측에서 접근할 수 있게 허용해주는 헤더를 지정합니다.

기본적으로 브라우저에게 노출이 되는 HTTP Response Header는 아래의 6가지 밖에 없습니다.

  • Cache-Control
  • Content-Language
  • Content-Type
  • Expires
  • Last-Modified
  • Pragma

다음과 같이 Access-Control-Expose-Headers를 Response Header에 지정하여 회신하면 브라우저 측에서 커스텀 헤더를 포함하여, 기본적으로는 접근할 수 없었던 Content-Length 헤더 정보도 알 수 있게 됩니다.

Response Header

Access-Control-Expose-Headers: Content-Length, X-My-Custom-Header, X-Another-Custom-Header

Access-Control-Max-Age

 Preflight Request의 결과가 캐쉬에 얼마나 오래동안 남아있는지를 나타냅니다.

Response Header

Access-Control-Max-Age: <delta-seconds>

Access-Control-Allow-Credentials

Request with Credential 방식이 사용될 수 있는지를 지정합니다.

Response Header

Access-Control-Allow-Credentials: true | false


Simple Request에 withCredentials = true가 지정되어 있는데, Response Header에 Access-Control-Allow-Credentials: true가 명시되어 있지 않다면, 그 Response는 브라우저에 의해 무시됩니다. 예비 요청에 대한 응답에 Access-Control-Allow-Credentials: false를 포함하면, 본 요청은 Request with Credential을 보낼 수 없습니다.

Access-Control-Allow-Methods

예비 요청에 대한 Response Header에 사용되며, 서버의 리소스에 접근할 수 있는 HTTP Method 방식을 지정합니다.

Response Header

Access-Control-Allow-Methods: <method>[, <method>]*

GET, POST, DELETE, PATCH 등등이 존재합니다.

Access-Control-Allow-Headers

 예비 요청에 대한 Response Header에 사용되며, 본 요청에서 사용할 수 있는 HTTP Header를 지정합니다.

Response Header

Access-Control-Allow-Headers: <field-name>[, <field-name>]*

Content-Type,Accept-Encoding, X-CSRF-Token, Authorization 등이 있습니다.

 

CORS 관련 HTTP Request Headers

클라이언트가 서버에 CORS 요청을 보낼 때 사용하는 헤더로, 브라우저가 자동으로 지정하며, XMLHttpRequest를 사용하는 프로그래머가 직접 지정해 줄 필요가 없습니다.

Origin

Cross-site 요청을 날리는 요청 도메인 URI을 나타내며, access control이 적용되는 모든 요청에 Origin 헤더는 반드시 포함됩니다.

Request Header

Origin: <origin>

<origin>은 공백일 수도 있는데, 소스가 data URL일 경우에 유용합니다.<origin>은 서버 이름(포트 포함)만 포함되며 경로 정보는 포함되지 않습니다.

Access-Control-Request-Method

예비 요청을 보낼 때 포함되어, 본 요청에서 어떤 HTTP Method를 사용할 지 서버에게 알려줍니다.

Request Header

Access-Control-Request-Method: <method>

<method>는 POST, GET, DELETE 등이 포함될 수 있습니다.

Access-Control-Request-Headers

예비 요청을 보낼 때 포함되어, 본 요청에서 어떤 HTTP Header를 사용할 지 서버에게 알려준다.

Request Header

Access-Control-Request-Headers: <field-name>[, <field-name>]*

Authorization, Content-type 등이 있습니다.

결론

  • CORS를 쓰면 AJAX로도 Same Origin Policy의 제약을 넘어 다른 도메인의 자원을 사용할 수 있음
  • CORS를 사용하려면 클라이언트에서 Access-Control-** 류의 HTTP Header를 서버에 보내야 하고, 서버도 Access-Control-** 류의 HTTP Header를 클라이언트에 회신하게 되어 있어야 함.


'' 카테고리의 다른 글

Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20

클러스터링이란?

클러스터링은 여러 개념에서 의미를 다르게 두지만 여기서 설명할 클러스터링이란 것은 여러대의 서버가 동시에 한가지 업무를 수행하도록 만드는 것입니다. 이를테면 DB가 한대 있는데 이 한대가 뻗으면 시스템 장애가 납니다 (SPOF - Single Point Of Failure). 만약 2대를 클러스터링 해 놓고 각각의 역할을 수행하다가 한놈이 뻗으면 나머지 한놈이 그 역할을 대신 수행하도록 하면 위와 같은 문제를 해결하면서 지속적인 서비스를 제공해줄 수 있게 됩니다.

세션 클러스터링이란?

세션 클러스터링은 WAS가 2대 이상 설치되어 있을 경우 동일한 세션으로 세션관리 하는 것을 의미합니다. 예를 들면 L4 스위치를 통해 2대 이상의 WAS가 연결되어 있을 경우, 일반적으로는 사용자는 접속했던 WAS로 L4 스위치가 접속을 유도해주지만 하나의 WAS에서 허용된 동접수를 초과한 접속이 발생할 경우 다른쪽으로의 접속을 유도해주게 됩니다. 그럴 경우, 기존 WAS의 세션이 아닌 새로이 접속된 WAS로 세션이 이루어지고 그럴 경우 세션에 대한 처리 불일치가 발생합니다. 그래서 각 WAS에 대한 세션을 하나의 세션으로 관리하게 함으로써 설사 사용자가 기존에 접속했던 WAS가 아닌 새로운 WAS로 접속하더라도 세션은 하나로 관리되기 때문에 세션에 대한 불일치가 발생하질 않습니다. 보통 세션 클러스터링은 WAS 설정으로 세팅할 수 있습니다. Tomcat에서 조차도 세션 클러스터링을 설정하는 방법이 있습니다. 사용하는 WAS마다 설정하는 방법이 다르니 관련 내용을 확인해야 합니다.

기타

Redis, infinispan 같은 별도의 세션서버를 두는 방법도 있습니다. Redis는 replication을 이용하면 클러스터링 기능도 가능하리라 봅니다.

세션 클러스터링을 사용하면 성능이 감소하긴하지만, 무시하고 사용할 정도로 떨어지진 않습니다.

로드밸런싱과 세션 클러스터링 차이점

로드 밸런싱은 클러스터링된 WAS의 한쪽에 부담이 가지 않게 하기 위해서 분산시켜주는 역할을 말합니다. 로드밸런싱이 보통 스위치 단에서 이루어지죠.

세션 클러스터링은 한쪽 부담이 가지않게 분산을 한다기 보단 하나의 서버의 장애를 방지하기 위해 임시방편 역할을 한다고 생각하면 됩니다.

'' 카테고리의 다른 글

Phantom JS란?  (0) 2017.10.22
CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20

개요

HTML5는 플래시나 실버라이트와 같은 플러그인 기반 응용프로그램에 대한 필요성을 줄이는 것에 초점을 맞추고 있다.

설명

HTML5라고 불리우는 개념은 단순히 웹 문서를 작성할 때 사용되는 마크업 랭귀지(HTML)의 문법적 (syntactic) 버전 뿐만 아니라 새로운 DOM API 스펙을 포함하는 것이다.

 문법면에서는 이전에 비해 상당히 간결하고 명확해 졌는데, 또한 이전에는 JavaScript를 사용해서 엄청나게 긴 코드를 써서 간접적으로 구현해야 했던 기능들이 정식 엘리먼트로 편입됨으로서 (예를 들어 <video> ) 간단하게 구현해낼 수 있게 되었고, 불필요하게 길게 적어야했던 이전 버전에서 꼭 필요한 부분만 남기도록 바뀌는 등 여러가지 개선점이 생겼다.

API면에서, HTML5에서는 비디오 및 오디오와 같은 미디어 엘리먼트에 대한 API뿐를 포함해 오프라인 웹 앱 구현, 문서 편집 등과 같은 다양한 기능에 대한 API가 추가되었으며 이전에는 플래시실버라이트 등의 외부 플러그인을 통해서만 지원할 수 있던 클라이언트 사이드에서의 사용자 인터페이스를 위한 기능들의 상당수를 브라우저 자체의 기능을 이용해 구현할 수 있게 되었다.

이런 API들은 사실상의 브라우저 표준 스크립트 언어인 JavaScript를 통해 이용할 수 있다. 이 때문에 HTML5는 마크업 언어라고만 보기는 더 이상 힘들어졌다. 단, HTML5 그 자체만으로 모든 것이 된다는 오해는 삼가자. HTML5 그 자체가 제공하는 것은 문서 구조와 API이고, 이걸 API와 연결시켜 실제 동작을 구현하는 것은 JavaScript라는 언어로, 이 둘은 엄연히 별개의 것이다. HTML5와 JavaScript가 서로 연결되어 돌아가는 개념이지, HTML5 안에 JavaScript가 포함되는 것이 절대로 아니다. 단적으로, JavaScript는 ECMAScript라는 표준안이 따로 나오는 별도의 프로그래밍 언어이다.

인터넷 익스플로러는 9부터 일부 태그를 지원하기 시작했고, 10에서 거의 대부분 지원한다. 8 이하를 지원하려면 html5shiv.js 라는 JavaScript를 이용하면 된다. 단 이 경우 JavaScript를 사용하기에 페이지 렌더링 속도가 느려진다는 단점이 있다. 그리고 위의 브라우저 API를 이용하는 기능들은 사용이 불가능하다. 이 JavaScript가 대체하는 것은 HTML5의 마크업 뿐이기 때문이다.

변경사항

HTML5로 접어들어 HTML이 다양한 기능을 포함하면서 새롭게 추가된 태그들과 의미가 변경된 태그들이 여럿 있다.

선언문

이전 버전의 HTML과 XHTML이 유효성 검사를 위한 선언문이 쓸데없이 길었던 반면, HTML5에서는 간단하게 몇 자만 적으면 된다.

<!DOCTYPE html>

시맨틱 태그

HTML5에서는 시맨틱 웹을 중요시하여 여러가지 태그를 새롭게 만들었다. 이러한 태그들을 시맨틱 태그라고 한다.

사실 기존 HTML 표준에서도 각 태그는 대부분 의미를 가지고 있었다. 그러나 의미를 가진 태그가 부족한 편이었고, 의미가 불명확한 태그나 시대의 흐름에 뒤쳐진 태그도 있었다. 2000년대 초반까지만 해도 테이블 관련 태그로 웹 페이지를 여러 구획으로 나눠서 레이아웃을 만드는 방식인 테이블 레이아웃(Table Layout)이 일반화 되어 있었다. 당시 CSS가 나온지 얼마 되지 않은데다 HTML의 기능이 부족할 때 레이아웃을 짜던 방식이 그대로 이어진 것이 원인이었다. 이에 2000년대 초반부터 시맨틱 웹이 중시되면서 HTML은 문서 구조와 의미, CSS는 디자인으로 확연히 분리되고, 테이블 레이아웃은 박스 모델 레이아웃으로 변화되었다. 그러나 당시 표준이었던 HTML 4.01과 XHTML 1.0으로는 시맨틱 웹을 구현하기가 난점이 있었다. 문서 내에 들어가는 목록이나 강조 등의 미시적인 부분에는 의미가 있었지만, 레이아웃에서 이게 메뉴인지 메인 컨텐츠인지 서브 컨텐츠인지 분류할 수 있는 태그는 없었다. 이 때문에 레이아웃에서 각 영역을 지정하는 태그는 <div>가 대단히 많이 쓰였고, 이 당시 박스 모델을 적용한 HTML 문서는 수십 개로 중첩된 복잡한 <div> 지옥(...)인 경우가 많았다. 이 때문에 HTML5에서 관련 태그를 추가한 것이다.

시맨틱 태그를 사용한 레이아웃은 컴퓨터가 읽어낼 수 있다. 검색 사이트에서 어디가 내용인지를 알 수 있어서 검색 노출을 용이하게하고, 궁극적으로 눈으로 페이지를 볼 수 없는 사람들에게 사이트의 어디가 본문인지 아닌지 알려줄 수 있다는 장점이 있다.

기존 태그는 일부분을 제외하고는 HTML 4.01에서 사용되던 태그가 거의 그대로 사용된다. 원래 HTML을 표준에 맞게 사용했다면 큰 어려움 없이 HTML5에도 적응할 수 있다.

레이아웃 태그

<header>

  • 일반적으로 페이지나 해당 섹션의 가장 윗부분에 위치한다. 페이지 맨 위에 쓸 때는 사이트의 제목이 보통 들어가며, 선택적으로 상단바나 검색창 등이 안에 들어갈 수 있다. <head> 태그랑 헷갈리면 매우 곤란하다. section이나 article, aside 등으로 묶어놓은 섹션 안의 헤더 용도로 사용해도 된다. 이건 아래 footer 태그도 마찬가지다.

<nav>

  • 내비게이션(navigation)의 약자로, 일반적으로 상단바 등 사이트를 안내하는 요소에 사용된다. 보통은 안에 <ul>을 넣어 목록 형태로 사용한다.

<article>

  • 웹 페이지의 내용에 사용하는 태그이다. 문서나 페이지, 사이트에서 독립적으로 배포 혹은 재사용(예를 들어 투고 같은)할 수 있는 섹션에 사용한다.

<section>

  • 웹 페이지의 섹션에 사용하는 태그이다. 웹 페이지를 의미적으로 각각의 파트로 구분하기 위해 쓰는 태그이다. 이 태그를 사용하면 검색엔진이 긁어가지 않는다는 이야기가 있는데 루머다. HTML5 표준 문서에 보면 "요소의 내용을 배포(syndicate)해도 이치에 맞다면 section 요소 대신 article 요소를 사용하기를 권합니다."라는 부분이 있는데, 이 부분의 해석이 잘못 퍼진 것으로 추정된다.

<aside>

  • 본문의 주요 부분을 표시하고 남은 부분을 설명하는 태그이다. 특별한 일이 아니면 사이드바나 광고창 등 중요하지 않은 부분에 사용된다.

<footer>

  • 일반적으로 페이지나 해당 파트의 가장 아랫부분에 위치한다. 페이지 맨 아래에 쓸 때는 사이트의 라이선스, 주소, 연락처 등을 넣는다.


<!DOCTYPE html>
<html lang="ko">
	<head>
		<meta charset="utf-8">
		<title>[페이지 제목]</title>
	</head>
	<body>
		<header>
			<h1>[사이트 제목]</h1>
			<h2>[사이트 부제목]</h2>
			<nav>
				<li>
			</nav>
		</header>
		<section>
			<article>
				[본문 내용]

			</article>
		</section>
		<aside>
			[사이드바 내용]
		</aside>
		<footer>
			<address>[주소 내용]</address>
		</footer>
	</body>
</html>

멀티미디어 태그

<audio>

  • 음성, 음악 파일 등을 재생할 수 있는 태그. 웹 브라우저마다 지원하는 확장자가 달라 멀티브라우저 지원을 위해서는 <source> 태그를 안에 넣어 두가지 이상의 확장자를 가진 음악 파일을 넣어야 한다. 가장 많이 사용하는 조합은 mp3+ogg

<video>

  • 영상 파일을 재생할 수 있는 태그. 사실상 HTML5에서 가장 주목받는 태그이다. 별다른 플러그인 없이도 자체 재생이 가능하다는 점이 가장 큰 장점이다. <audio> 태그와 마찬가지로 <source> 태그를 넣어 mp4+ogv의 조합으로 짜주면 거의 대부분의 브라우저를 지원한다.

<canvas>

  • 스크립트를 이용하여 그래픽을 표현하는 태그이다. 일반적으로는 JavaScript를 많이 사용하며, 응용하면 웹에서 게임앱, 3D 엔진 등을 돌리는 다양한 응용이 가능하다.

폼 관련

<output>

  • 계산의 결과값을 전송하는 데에 쓰인다.
  • 새로운 <input>의 type 속성 - date, datetime, time, color, range 등
    JavaScript를 통해서만 구현됐던 기능이 내장되었다. 현 시점에서는 크롬이 사실상 전부를 지원한다.

<datalist>

  • <input>의 type="text"와 같은 속성을 가진 것들에 들어갈 값을 미리 정의하는 태그이다.

<keygen>

  • 암호화용 키쌍을 생성하는 태그이다. 서버에는 공개 키가 전송되고, 개인 키는 클라이언트에 저장된다. 현재 whatwg 스펙에서 제거되었다. 그러나 w3c 스펙 상에는 아직 없어지지 않은 상태.

기타 태그

<menu>

  • 툴바, 팝업 메뉴를 넣을 때 쓴다.

<menuitem>

  • 툴바, 팝업 메뉴의 각 항목을 정의한다.

<details>

  • 보이거나 숨기게 해주는 요약글 형식의 위젯에 사용되는 태그이다. <summary> 태그와 함께 쓰인다.

<embed>

  • 외부 애플리케이션이나 플러그인을 삽입할 때 쓰는 태그이다. 대표적으로 어도비 플래시를 웹페이지에 삽입할 때 이걸 쓴다. 그 외에도 예전에는 IE 전용 태그 중 하나인 <bgsound> 태그를 대체하는 태그로도 쓰인 바 있다. 원래 HTML에 없던 비표준 태그였는데 거의 모든 브라우저가 이 태그를 지원한데다, 기존에 표준으로 존재하던 object 태그보다 사용방법이 간편해서 사실상 표준처럼 쓰이던 태그였고 결국 HTML5 표준에 포함되었다.

<object>

  • 외부 문서, 매체, 플러그인 등을 웹페이지에 삽입할 때 쓰는 태그이다.

<figure>

  • 그림, 도표, 다이어그램 등의 글의 이해를 돕기 위한 내용들을 나타내는 태그이다.

<figcaption>

  • <figure> 태그 안에 사용되는 태그로, <figure> 태그 안에 있는 내용의 설명을 적는 태그이다.

용도가 바뀐 태그

<s>

  • 더이상 옳지 않은 내용을 나타내는 데에 쓴다. 별도의 CSS 없이 쓰면 브라우저에서는 취소선을 긋는 것이 기본값이다.

<u>

  • 양식상 일반적인 텍스트보다 돋보여야 할때 쓴다. 예를 들어 철자가 틀린 단어나, 중국어로 번역된 고유 명사 등이 있다. 별도의 CSS 없이 쓰면 브라우저에서는 밑줄을 긋는 것이 기본값이다.

<i>

  • 어떠한 이유로 일반적인 텍스트보다 돋보여야 할때 쓴다. 예를 들어 전문 용어, 외국어의 구절 등이 있다. 별도의 CSS 없이 쓰면 브라우저에서는 이탤릭체로 표기하는 것이 기본값이다.
  • 더 적절한 시맨틱 태그가 있을 경우 그쪽을 쓴다.

<hr>

  • 원래 단순한 가로줄을 나타내는 태그였으나, 페이지의 주제가 바뀔 때 내용을 분리시키는 의미가 HTML5에서 추가되었다

사용 불가 태그

대개 시맨틱 웹에서 사용을 지양하는 태그라든가, 특정 브라우저대표적으로 IE라든가에서만 작동하는 태그가 속한다.

<font>

  • CSS가 있기 때문에 폐기되었다. 이미 HTML 4.01에서 비권장으로 분류된 태그였다. CSS의 font-family, font-size로 대체된다.

<center>

  • 가운데 정렬용 태그인데 마찬가지로 CSS로 너무나도 간단하게 대체 가능하기에 폐기되었다. 텍스트 및 인라인 요소 가운데 정렬은 text-align: center;로, 블럭 요소 가운데 정렬은 margin:0 auto;로 대체 가능하다.

<basefont>

  • 말 그대로 기본 폰트를 지정해 주는 태그였다. 하지만 CSS가 있는데 굳이 이걸 쓸 이유가... 결국 IE 9를 끝으로 여러 브라우저에서 더 이상 이 태그를 지원하지 않는 등 존재가 유명무실해진 까닭에 너무나도 당연히 폐기되었다. 모든 태그에 CSS 속성을 적용하는 선택자로 대체가 가능하다.

<applet>

  • 자바 애플릿을 넣을 때 쓰는 태그였다. <object><embed>로 대체한다.

<strike>

  • <del><s>로 대체되었다.

<frame>

  • 이것과 함께 쓰이던 <frameset>, <noframes> 태그 역시 함께 사용 불가 태그가 되었다. 또한 이게 없어지면서 frameset 속성의 문서도 없어졌다. HTML5에서 프레임을 가진 문서는 <iframe>으로 비슷하게 구현할 수 있다.

<acronym>

  • <abbr>와 의미가 중복되어서 <abbr>로 통합되었다.

<marquee>

  • 익스플로러에서 전광판처럼 글자가 흐르게 하는 테그였다. JavaScript나 CSS3의 Animation으로 대체할 수 있다.

<blink>

  • 넷스케이프와 파이어폭스에서 글자를 깜빡이게 하는 태그였다. 이 역시 JavaScript나 CSS3의 Animation으로 대체할 수 있다.

<bgsound>

  • 배경음악을 재생시키는 태그인데 익스플로러에서만 돌아가는 비표준 태그이다. 다른 브라우저를 배려하기 위한 차원에서 범용성이 좋은 <embed>로 대체해 가는 추세였으며, HTML5에서 <audio>가 추가되었으므로 더 이상 필요하지 않다.


'' 카테고리의 다른 글

CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20
세션, 쿠키, 캐시  (0) 2016.05.21

웹 서버와 WAS(Web Application Server)의 정의 

웹서버와 WAS는 비슷한 개념이기 때문에 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷 확산 초기에는 웹서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 WAS를 더 많이 사용하고 있다. 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 layer를 나누게 되었고 여기서 웹서버와 WAS의 구분점이 생기게 된 것이다.

기능적으로만 본다면, 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 WAS라고 부르는 것보다는 어떤 기능을 수행하는지에 따라, 즉 기능상의 분류를 통해 구분지어 사용해야 할 것이다. 


구분

웹서버

WAS

설명

  1. 웹브라우저(Web Client)에게 컨텐츠를 제공하는 서버이다. 즉 정적인 HTML이나 jpeg, gif같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공한다.
  2. 최근에는 웹서버에서도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다.

서버단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 이 후에는 Servlet, ASP, JSP, ASP, PHP등의 프로그램으로 사용되고 있다.


웹 서버와 WAS(Web Application Server)의 구성에 따른 분류

기본적인 웹 사이트 구성


<그림 1>은 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 WAS의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성시 활용의 가치가 높다.

  • 장점 : 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러대의 WAS를 통해 지원이 가능하다.필요시에 추가로 WAS를 증설하는 구조라고 볼 수 있다.
  • 단점 : WAS가 정적인 데이터(HTML/Image)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에 최적화 측면에선 바람직하지 않다. 또한 정적데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있고, 그 반대의 경우도 있다.

웹 서버와 WAS로 구성된 환경

 


<그림 2>는 웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 WAS가 처리한다. 사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, Image 등을 앞단의 웹 서버에 위치시켜 처리함으로써 WAS로 서비스 요청이 넘어가지 않게 한다. 또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 WAS에 넘겨줌으로써 WAS는 웹 애플이케이션의 수행이 집중할 수 있다. 웹 서버 단에서 처리할 것과 WAS에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 Configuration을 통해 처리할 수 있다. 특정 확장자나 디렉토리 업무를 WAS로 넘길지 여부는 웹 서버 단에서 처리한다.

특정기능에 대한 서버를 별도로 두고 있는 환경

 


점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 WAS를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다. 또는 특정 콘텐츠에만 집중적인 요청을 받는 경우도 있다. 예를 들어, 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, Reload 또한 빈번하게 일어나므로 특정시간 간격으로 HTML을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다.

  • 장점 : 다양한 환경에 대한 대처가 빠름
  • 단점 : 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰임

WAS단을 Logic으로 구분하여 구성

 


<그림 4>는 <그림 2>의 변경된 형태이다. WAS단의 프로그램이 많은 비중을 차지하는 경우, Presentation Logic을 담당하는 프로그램과 Business Logic을 담당하는 프로그램을 구분하는 구성이다. 이런 구성은 특정 로직 부분의 부하에 따라 적절한 대응을 할 수 있으나 구조가 복잡해지는 단점이 있다.

WAS 관련 용어 정의

자바 서블릿(Java Servlet)

자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말하며, 흔히 “서블릿”이라고 한다. 자바 서블릿은 Java EE사양의 일부분으로, 주로 이 기능을 이용하여 쇼핑몰이나 온라인 뱅킹 등의 다양한 웹 시스템이 구현되고 있다. 비슷한 기술로는 펄 등을 이용한 CGI, PHP를 아파치 웹 서버 프로세스에서 동작하게 하는 mod_php, 마이크로소프트사의 IIS에서 동작하는 ASP 등이 있다. CGI는 요청이 있을 때마다 새로운 프로세스가 생성되어 응답하는 데 비해, 자바 서블릿은 외부 요청마다 프로세스보다 가벼운 쓰레드로써 응답하므로 보다 가볍다. 또한 자바 서블릿은 자바로 구현되므로 다양한 플랫폼에서 동작한다.

엔터프라이즈 자바빈즈(Enterprise JavaBeans, EJB)

EJB는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB사양은 Java EE의 자바 API중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리한다. EJB의 종류는 세션 빈(Session Bean), 엔티티 빈(Entity Bean), 메시지 구동 빈(Message-driven Bean)이 있다.

자바 메시지 서비스(Java Message Service, JMS)

JMS는 자바 프로그램이 네트워크를 통해 데이터를 송수신하는 자바 API이다.

자바 가상 머신(Java Virtual Machine, JVM)

JVM은 자바 바이트코드를 수행할 수 있는 환경이다. 자바 바이트코드는 주로 자바를 컴파일하여 생성하지만, 다른 언어의 컴파일러에서도 생성할 수 있다. 자바 가상 머신은 자바 플랫폼의 기반을 이루며 다양한 하드웨어 기반 플랫폼에 포팅된다. JVM은 자바 플랫폼의 주요한 부분이며 마이크로소프트 윈도(95/98/NT), 리눅스, 유닉스, 맥오에스 텐 등 대부분의 운영체제는 물론, 인터넷 익스플로러와 넷스케이프 등과 같은 웹 브라우저 등 여러 가지 플랫폼에 설치되어 사용될 수 있으며, 휴대전화나 가전기기에도 설치할 수 있다. 따라서 자바 플랫폼은 여러 플랫폼을 지원하여 미들웨어로서의 역할과 플랫폼 스스로의 역할을 동시에 수행할 수 있다. 사용자는 자바 바이트코드로 컴파일된 자바 프로그램을 실행시키기 위해서 이 자바 가상머신을 이용하면 된다.

원 개발사인 썬 마이크로시스템즈에서 자바 가상 머신의 기준이 되는 표준판(Java SE) 과 표준판을 핸드폰이나PDA 등 임베디드 기기용인 축소판(Java ME) 으로 구분하여 가상 머신을 배포하고 있다. 기업판(Java EE)의 경우에는 표준판의 자바 가상 머신을 기반으로 확장된 라이브러리 집합을 정의한 것이기 때문에 자바 가상 머신의 종류로 분류하기 애매하다. 썬 마이크로시스템즈에서 제공하는 자바 가상 머신 말고도 각 운영체제 개발사가 제공하는 자바 가상 머신이 있으며, GNU의 GCJ나 아파치 소프트웨어 재단(ASF: Apache Software Foundation)의 하모니(Harmony)와 같은 오픈 소스 자바 가상 머신도 존재한다. 이러한 공개 소프트웨어 단체의 움직임에 따라 썬 마이크로시스템즈에서도 자사의 자바 가상 머신 및 개발 도구 킷을 오픈 소스 정책에 맞추어 공개한 상황이다.

힙 메모리(heap memory)

프로그램을 사용할 수 있는 자유 메모리. 프로그램 실행 시에 함수로 보내는 데이터 등을 일시적으로 보관해 두는 소량의 메모리와 필요시 언제나 사용할 수 있는 대량의 메모리가 있다. 이때, 소량의 메모리를 ‘스택’이라 하고 대량의 메모리를 ‘힙’이라 한다. 이 ‘힙’이 없어지면 메모리 부족으로 ‘이상 종료’하게 된다.

자바 서버 페이지(JavaServer Pages, JSP)

HTML내에 자바 코드를 삽입하여 웹 서버에서 동적으로 웹 페이지를 생성하여 웹 브라우저에 돌려주는 언어이다. Java EE 스펙 중 일부로 웹 애플리케이션 서버에서 동작한다. 자바 서버 페이지는 실행시에는 자바 서블릿으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만, 서블릿과는 HTML 표준에 따라 작성되므로 웹 디자인하기에 편리하다. 이와 비슷한 구조인 것인 PHP, ASP, ASP.NET 등도 있다. 아파치 스트럿츠나 자카르타 프로젝트의 JSTL 등의 JSP 태그 라이브러리를 사용하는 경우에는 자바 코딩없이 태그만으로 간략히 기술이 가능하므로 생산성을 높일 수 있다.

클라이언트에서 서비스가 요청되면, JSP의 실행을 요구하고, JSP는 웹 애플리케이션 서버의 서블릿 컨테이너에서 서블릿 원시코드로 변환된다. 그 후에 서블릿 원시코드는 바로 컴파일된 후 실행되어 결과를 HTML 형태로 클라이언트에 돌려준다.

Java Database Connectivity(JDBC)

자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API이다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다. JDBC는 Java로 작성된 프로그램을, 일반 데이터베이스에 연결하기 위한 응용프로그램 인터페이스 규격입니다. 이 응용프로그램 인터페이스는 데이터베이스 관리 시스템에 넘겨질 SQL 형태의 데이터베이스 접근요구 문장을, 각 시스템에 맞도록 바꾸어준다. API는 동적으로 올바른 Java 패키지를 로드하고, JDBC 드라이버 매니저에 등록하기 위한 메커니즘을 제공합니다. 드라이버 매니저가, JDBC connection을 생성하기 위한 connection factory로서 사용됩니다.

Java Management eXtensions(JMX)

응용 프로그램 소프트웨어/객체/장치 (프린터 등) 및 서비스 지향 네트워크 등을 감시 관리를 위한 도구를 제공하기 위한 자바 API이다. 이러한 리소스는 MBean(Managed Bean)이라는 객체로 표현된다.

Java Naming and Directory Interface(JNDI)

디렉터리 서비스에서 제공하는 데이터 및 객체를 발견(discover)하고 참고(lookup)하기 위한 자바 API이다.

'' 카테고리의 다른 글

CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20
세션, 쿠키, 캐시  (0) 2016.05.21

Rest API란

REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 된다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현.

무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있다.

웹 아키텍처

  1.  클라이언트/서버 (Client/Server)
  2. 균일한 인터페이스 (Uniform Interface)
  3. 계층 시스템 (Layered System)
  4. 캐시 (Cache)
  5. 상태 없음 (Stateless)
  6. 주문형 코드 (Code-on-demand)

클라이언트/서버

균일한 인터페이스

웹을 구성하는 클라이언트, 서버, 네트워크 등의 인터페이스 (웹 컴포넌트들) 중 하나라도 표준에서 벗어나면, 웹 커뮤니케이션 체계는 붕괴된다. 웹 컴포넌트들은 다음 제약에 따라 서로 일관성 있게 상호 운영된다.

  1. 리소스 식별
  2. 표현을 통한 리소스 처리
  3. 자기-서술적 메시지 (Self-descriptive messages)
  4. 애플리케이션 상태 엔진으로서의 하이퍼미디어(HATEOAS07)

리소스 식별

리소스는 웹 상에서 서로 구별할 수 있는 URI와 같은 개념으로 볼 수 있다.

표현을 통한 리소스 처리

클라이언트는 리소스 표현을 처리한다. 같은 리소스라도 표현방식은 달라질 수 있다. 예로 문서가 웹에서 HTML로 표현되지만 타 프로그램에서는 JSON으로 표현될 수 있다. 이러한 표현이 다양하다고 해서 리소스, 식별자 자체가 변하지는 않는다.

자기-서술적 메시지

자기-서술적 메시지는 메타데이터를 포함하는데, 메타데이터에는 리소스의 상태, 표현 형식과 크기, 메세지, 자신에 대한 추가 정보등 이 포함되어 있다. HTTP 메세지는 일정한 형태로 여러 종류의 메타데이터 정보를 넣을 수 있는 헤더를 제공한다.

애플리케이션 상태 엔진으로서의 하이퍼미디어

계층 시스템

계층 시스템이라는 제약조건은 프락시 또는 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다. 웹의 일관된 인터페이스를 사용하면 중간매체를 클라이언트와 서버 사이에 마치 없는 것처럼 배치할 수 있다. 일반적으로 네트워크 기반의 중간매체는 특별한 목적을 위해 클라이언트와 서버간 통신을 가로챌 수 있다. 네트워크 기반의 중간매체는 보통 보안을 강화하거나,응답을 캐싱하거나, 부하를 분산하는 용도로 사용한다.

캐시

캐시는 웹 구조의 중요 제약조건 중 하나다. 캐시라는 제약조건에 의해 웹 서버가 응답 데이터마다 캐시 여부를 선언한다. 캐싱 응답 데이터는 클라이언트가 느끼는 지연을 감소시키고 애플리케이션의 전체적인 이용 가능성과 안정성을 향상시키며, 웹 서버의 부하를 제어한다. 다시 말해, 캐싱08은 웹의 전체적인 비용을 낮출 수 있는 중요한 방법이다. 캐시는 클라이언트와 서버 사이의 네트워크 경로라면 어디에라도 위치할 수 있다. 웹 서버단, 콘텐츠 전송망CDN단, 또는 클라이언트 내에도 가능하다.

상태 없음

상태 없음 제약조건은 웹 서버가 클라이언트의 상태를 관리할 필요가 없다는 의미다. 따라서 각 클라이언트는 웹 서버와 상호작용하는 관련 상황 정보를 직접 관리해야 한다. 웹 서버는 웹 애플리케이션과의 복잡한 커뮤니케이션을 위해 필요한 상태 관리를 클라이언트에 맡김으로써 더 많은 클라이언트에 서비스할 수 있다. 이러

한 트레이드오프는 웹 구조적인 스타일의 확장성에 이바지하는 주요 요소다.

주문형 코드

웹은 주문형 코드Code-On-Demand를 아주 많이 사용한다. 이 제약조건은 스크립트나 플러그인 같은 실행 가능한 프로그램을 일시적으로 클라이언트에 전송하여, 클라이언트가 실행할 수 있도록 한다. 주문형 코드는 웹 서버와 클라이언트 사이에 기술적 결합을 만들어내기도 하는데, 클라이언트는 필요할 때마다 서버에서 내려받은 실행 코드를 이해해야 하기 때문이다. 이러한 이유로 주문형 코드는 웹의 구조적 스타일에서 유일한 선택사항이다. 주문형 코드 제약사항의 예로 자바 애플릿, 자바스크립트, 플래시 같은 웹 브라우저 기반의 기술들이 있다.

URI 규칙

  • 슬래시 (/)는 계층관계를 나타내는데 사용

  • 마지막 문자로 슬래시를 포함하지 않음
  • 하이픈(-)은 URI 가독성을 높이는데 사용
  • 밑줄(_)은 URI에 사용하지 않음
  • URI 경로에는 소문자가 적합
  • 파일확장자는 URI에 포함시키지 않음
  • API에 있어 서브 도메인은 일관성 있게 사용

리소스 원형

도큐먼트 (단수명사, 명사의 조합)

도큐먼트리소스는 객체 인스턴스나 데이터베이스 레코드와 유사한 단일개념이다. 도큐먼트는 값을 가지고 있는 필드와 다른 관련 리소스와의 링크 둘 다를 가진다.

컬렉션 (복수명사)

컬렉션 리소스는 서버에서 관리하는 디렉터리 리소스이다. 클라이언트는 새로운 리소스를 제안해서 컬렉션에 포함할 수 있다. 

스토어

스토어는 클라이언트에서 관리하는 리소스 저장소이다. 스토어 리소스는 API 클라이언트가 리소스를 넣거나 지우고, 업데이트 하는 것을 말한다. 스토어는 스스로 새로운 리소스를 생성하지 못하기 때문에 새로운 URI를 만들지는 못한다.

컨트롤러(동사)

기본으로 GET, PUT, POST, DELETE 요청에 1:1매치 되는 개념인 CRUD가 존재하며 CRUD의 앞글자들을 풀어보면 Create, Read, Update, Delete가 될 텐데, 각각 POST, GET, PUT, DELETE에 대응되는 개념이다. 그런데 사실 URI를 디자인 하다 보면 이러한 방식으로 나타내기 참 어려운 경우를 많이 만나게 된다. 그 중 가장 많은 경우가 어떤 특정한 행위를 요청하는 경우이다. 많은 분이 이럴 때 동사를 쓰는데, 앞선 포스팅에서 밝혔듯이 동사를 써서 URI를 디자인하는 것은 대체로 옳지 않은 방식으로 여겨진다.

이럴 때 컨트롤러 리소스를 정의하여 이 문제를 해결할 수 있다. 컨트롤러 리소스는 URI 경로의 제일 마지막 부분에 동사의 형태로 표시되어 해당 URI를 통해 접근했을 때 일어날 행위를 생성한다. (개념적으로는 이렇게 이해하면 됨) 생성과 관련된 요청이 POST이기 때문에 컨트롤러 리소스에 접근하려면 POST 요청을 보내야 함.

http://api.college.restapi.org/students/morgan/register
리소스 morgan을 등록

http://api.ognom.restapi.org/dbs/reindex
리소스 dbs를 재색인

http://api.build.restapi.org/qa/nightly/runTestSuite
리소스 nightly에 테스트를 수행

그리고 마치 프로그램의 함수처럼 컨트롤러 리소스에는 입력값을 전달할 수 있음. 그것은 POST 요청의 엔티티 바디에 포함되어야 함. 그리고 역시 함수에서 반환값을 돌려주듯이 컨트롤러 리소스에서는 해당 입력 값에 대한 응답 값을 돌려주어야 함.

규칙

  • 도큐먼트 이름은 단수 명사로 사용
  • 컬렉션 이름은 복수명사로 사용
  • 스토어 이름은 복수명사
  • 경로 부분 중 변하는 부분은 유일한 값(고유 값)으로 대체
  • Crud기능을 나타내는 것은 URI에 사용하지 않음
  • URI 쿼리 부분으로 컬렉션이나 스토어를 필터링 할 수 있음
    • GET/users?role=admin     - 응답 메시지의 상태표현은 컬렉션에 있는 사용자 중 'role'의 값이 'admin'인 사용자의 리스트
  • URI 쿼리는 컬렉션이나 스토어의 결과를 페이지로 구분하여 나타내는데 사용

컬렉션과 도큐먼트

도큐먼트는 우리말로 문서로 이해해도 되고, 정보라고 이해해도 무관. 도큐먼트는 엘리먼트(element)라고도 불림 컬렉션은 정보(문서)들의 집합. 컬렉션과 도큐먼트는 모두 리소스라고 표현할 수 있으며 URI에 표기가 됨

http://www.remotty.com/sports/soccer
http://www.remotty.com/sports/soccer/players
http://www.remotty.com/sports/soccer/players/13/skills

http://www.remotty.com/sports는 컬렉션임. sports컬렉션에 soccer도큐먼트가 존재하고 soccer도큐먼트에 player이라는 컬렉션이 존재함. players컬렉션에 등번호가 13번인 선수가 존재한다고 가정하면 여기서 13은 도큐먼트이다. soccer 도큐먼트와 동일한 수준의 다른 도큐먼트는 baseballmarathon 등이 있다고 볼 수 있다. 그 하위의 players의 컬렉션과 동일한 수준의 컬렉션은 뭐가있을지 생각해보면  rulesleagues 등이 존재할 것이다.

HTTP Method에 맞는 역할

HTTP Method는 여러가지가 있지만 REST API에서는 4개 혹은 5개의 Method만 사용됨. POSTGETPUTDELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있음. 그러나 REST API에서 사용되는 개수는 4개 혹은 5개라고 한 이유는 PATCH를 포함하면 5개가 되기 때문.

각 Method마다 올바른 역할이 존재

URI
POSTGETPUTDELETE
http://www.remotty.com/sports
12

 http://www.remotty.com/sports/soccer

345

번호를 이용하여 설명하겠습니다.

  1. 현재 리소스 보다 한단계 아래에 리소스를 생성. POST Method를 통해 해당 URI를 요청하면 sports 컬렉션에 알맞은 soccer 또는 baseball과 같은 도큐먼트 리소스를 생성.
  2. 현재 리소스를 조회. 보통 컬렉션 리소스를 조회하게되면 하위의 도큐먼트들의 목록과 아주 간단한 정보들을 가져옴.
  3. 현재 리소스를 조회. 도큐먼트 리소스를 조회하게되면 해당 도큐먼트에 대한 자세한 정보들을 가져옴.
  4. 현재 리소스를 수정. soccer에 대한 정보를 수정하게 됨.
  5. 현재 리소스를 삭제. DELETE Method를 이용하여 현재 URI를 호출하면 sports 컬렉션에서 soccer 도큐먼트가 삭제.

추가로 주목해볼 만한 Method는 PATCH인데 기존에 REST에 익숙하신분들은 수정(update)을 위한 Method는 PUT가 익숙하지만 앞으로는 PUT대신 PATCH를 자주 써야할꺼 같음.

자세한 설명은 Edge Rails: PATCH is the new primary HTTP method for updates

요청 메소드

규칙

  • GET 메서드나 POST 메서드를 사용해 다른 요청 메서드 처리를 하면 안됨
    • 터널링tunneling은 메시지의 원래 의도를 감추거나 잘못 표현하는 것, 프로토콜의 투명성을 훼손하는 것 등의 HTTP 오용을 의미한다.

  • GET 메서드는 리소스의 상태표현을 얻는 데 사용
  • 응답헤더를 가져올 때 반드시 HEAD 메서드를 사용
    • GET 메서드와 동일하지만 바디가 존재하지 않음
  • POST 메서드는 컨트롤러를 실행하는 데 사용
    • HTTP 표준에서는 POST 메서드에 의미상 제한을 두지 않음
  • PUT메서드는 리소스를 삽입하거나 저장된 리소스를 갱신하는데 사용
  • PUT 메서드는 변경 가능한 리소스를 갱신하는데 사용
  • POST 메서드는 컬렉션에 새로운 리소스를 만드는 데 사용
  • DELETE 메서드는 그 부모의 리소스를 삭제하는데 사용
  • OPTIONS 메서드는 리소스의 사용가능한 인터낵션을 기술한 메타데이터를 가져오는 데 사용
    • OPTIONS 메서드를 사용하여 Allow 헤더에 포함된 리소스 메타데이터를 가져옴. (다음처럼 사용가능한 메서드를 가져옴 : Allow: GET, PUT, DELETE

응답상태코드

응답코드

코드이름의미
200OK

성공

201Created

새로운 리소스가 추가되었음을 알리기 위해 컬렉션이나 스토어에서 보내는 상태다. 어떤 경우에는 컨트롤러에서 보낼 수도 있다 

202Accepted

비동기 액션이 시작되었음을 알리기 위해 컨트롤러에서 보낸다. 

204No Content

바디 부분이 의도적으로 비어 있는 상태임을 나타낸다. 

301Moved Permanently

클라이언트가 요청한 리소스에 새로운 영구 URI가 할당되었음을 가리 

303See Other

컨트롤러에서 옵션인 결과를 돌려줄 때 보낸다. 

304Not Modified

조건 GET에 대해 대역폭을 보호하기 위해 보낸다. 

307Temporary Redirect

클라이언트가 요청한 리소스에 새로운 임시 URI가 할당되었음을 가리 킨다. 

400Bad Request

특별한 일이 없는 클라이언트의 에러 상태를 가리키는 오류 코드다. 

401Unauthorized

클라이언트에서 유효하지 않은 자격 증명을 보내거나 자격 증명을 보내지 않은 경우 보내는 오류 코드다. 

402Forbidden

보호된 리소스의 접근을 거부할 때 보내는 오류 코드다. 

404not Found

클라이언트가 URI에 대해 상호작용하고자 하였으나, REST API에서 URI 를 특정 리소스로 대응할 수 없을 때 보내는 오류 코드다. 

405Method Not Allowed

클라이언트에서 지원하지 않는 HTTP 메서드를 사용하여 상호작용하고자 할 때 보내는 상태 코드다. 

406Not Acceptable

클라이언트에서 지원하지 않는 미디어 타입 형식의 데이터를 요청할 때 보 내는 오류 코드다. 

409Conflict

클라이언트에서 리소스 상태를 위반하는 시도를 하고 있음을 나타내는 오 류 코드다. 

412Precondition Failed

선행 조건 중 하나가 만족되지 않았음을 클라이언트에게 알리는 오류 코 드다. 

415Unsupported Media Type

지원하지 않는 미디어 타입 형식으로 클라이언트에서 데이터를 제출하였음 을 알리는 오류 코드다. 

500Internal Server Error

API가 내부에서 문제가 생겼음을 클라이언트에게 알리는 오류 코드다. 

HTTP 헤더

규칙

  • Content-Type을 사용해야함.
    • (Content-Type 헤더는 요청이나 응답 메시지 바디에 있는 데이터 타입을 나타내기때문에 메시지 바디에 있는 바이트열 처리방법을 결정할 수 있음)
  • Content-Length를 사용해야함.
    • (Content-Length 헤더는 바이트 단위로 바디의 크기를 나타냄. 클라이언트는 이 값을 사용해 바이트의 크기가 올바르게 읽혔는지 알수 있고 HEAD요청으로 데이터의 크기를 확인할 수 있음)
  • Last-Modified는 응답에 사용.
    • (이 응답 헤더의 값은 타임스탬프로 리소스의 표현 상태값이 바뀐 마지막 시간을 나타냄. 클라이언트와 캐시 중간자는 이 헤더를 사용해 갱신여부를 결정)
  • ETag는 응답에 사용. 
    • (응답 엔티티에 포함된 표현 상태의 특정버전을 나타내는 일련의 문자열)
  • 스토어는 조건부 PUT요청을 지원해야함.
    • (PUT메서드를 사용해 스토어에 리소스를 추가하거나 갱신할 수 있어서 REST API는 클라이언트의 If-Unmodified-Since와 If-Match 요청 헤더를 통해 클라이언트의 의도를 파악할 수 있음)
  • Location은 새로 생성된 리소스의 URI를 나타내는데 사용.
    • (Location 응답 헤더의 값은 클라이언트의 관심 범위에 있는 리소스를 식별하는 URI)
  • Cache-Control, Expires, Date 응답헤더는 캐시 사용을 권장하는데 사용해야 함.
    • (캐시는 클라이언트의 대기시간을 줄일 수 있고 신뢰성 향상, api 서버의 부하감소 등 장점이 있음)
  • Cache-Control, Expires, Pragma 응답헤더는 캐시 사용을 중지하는데 사용해야 함.
  • 캐시 기능은 사용해야함.
    • (no-cache 지시자는 캐시 응답이 제공되는 것을 막음. REST API는 꼭 필요한 경우가 아니면 캐시를 사용하지 않는다. no-cache 보다 값이 작은 max-age를 사용하면 클라이언트는 갱신에 관계없이 짧은 시간 내 캐시에 저장된 복사본을 가져올 수 있음)
  • 만기 캐싱 헤더는 200응답에 사용.
    • (만기 캐싱 헤더는 성공적인 GET메서드와 HEAD 메서드의 요청에 대한 응답으로 설정)
  • 만기 캐싱 헤더는 3xx와 4xx 응답에 선택적으로 사용될 수 있음
    • (200 응답코드를 보낸 성공적인 응답에 추가로 3xx와 4xx 응답에 대한 캐싱 헤더를 추가하는 것을 네거티브캐싱 이라 하는데 리다이렉트 횟수와 REST API에 오류에 따른 부하를 감소시킴

메시지 바디 포맷

규칙

  • JSON 리소스 표현을 지원해야함 
    • (JSON은 가볍고 간단한 상호 연동을 지원.)
  • JSON은 문법에 잘 맞아야 함
    • (key-value 로 구성되며 순서와 무관. JSON은 숫자를 지원하기 때문에 문자열로 처리할 필요 없고 시간과 날짜는 지원하지 않음.)
    • JSON에 이름을 붙일 때 소문자,대문자를 섞어쓰고 특수 문자는 피해야 함.
  • XML과 다른 표현 형식은 선택적으로 지원할 수 있음

오류표현

규칙

  • 오류는 일관성 있게 표현

지원적 문제

  • 서버 구현 모델과 리소스 모델 간 자연스러운 분리
  • 일관된 크로스 포맷 하이퍼미디어 구조
  • 부분적이면서 동적으로 구성되는 응답 바디
  • 클라이언트 식별과 자격 권한의 통합


'' 카테고리의 다른 글

CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20
세션, 쿠키, 캐시  (0) 2016.05.21

세션과 쿠키, 캐시의 정의에 대해 매번 햇갈려 정리합니다. 

1. Stateless 프로토콜

기본적인 HTTP통신의 원칙은 Stateless입니다. 클라이언트의 상태를 가지지 않는 서버 처리 방식을 말합니다. 다시 말해, 클라이언트와의 첫번째 통신에서 데이터를 받았다고 해도 두번째 통신에서 이 데이터를 계승하지 않는 처리 방식입니다. 하지만 실제 서비스에서는 이와 같은 기본 원칙보다 Stateful한 방식이 필요한 경우가 많습니다. 예를 들어, 상품을 선택하고, 구입을 하는 예를 생각해 봅니다. 상품 선택의 통신이 끝난후, 상품 구입의 리퀘스트가 서버로 보내지게 될 터인데, 여기서 만약 서버가 선택한 상품의 정보(상태)를 가지고 있지 않다면 유저는 상품을 구입 할 수가 없습니다. 따라서 웹 어플리케이션 개발자는 이런 HTTP의 stateless 특성 위에 stateful과 같은 시스템을 개발 할 필요가 생기게 됩니다. 

Stateful을 가능하게 만든 방법으로 쿠키와 세션이 있습니다. 두개의 큰 차이는 상태정보를 어디에 저장하는지 입니다. 쿠키는 브라우저에 의해 클라이언트 측에 저장되고 세션은 서버 측에 저장됩니다.

만약 세션을 사용하면 특정 클라이언트가 무엇을 요청하는지 저장되어 있어 요청에 대한 응답을 실행하지만 쿠키의 경우 서버는 특정 클라이언트가 무엇을 주문했는지 기억하지 않고 클라이언트가 저장되어 있는 이전 데이터를 불러와 반복적으로 서버에게 요청합니다.

쿠키

쿠키는 브라우저에 보존되고, 통신시에 HTTP 헤더에 저장되어지는 텍스트 파일입니다. 쿠키를 이용한 실제의 stateful 통신의 흐름은 다음과 같습니다.

  1. 최초 통신에서는 클라이언트가 서버의 쿠키를 가지고 있지 않은 상태에서 request한다.
  2. 서버는 request의 헤더에 쿠키가 포함되어 있지 않은것을 판단하고, 통신의 상태(유저ID, 패스워드, 조작상태, 방문횟수 등)을 저장한 쿠키를 response한다.
  3. 클라이언트의 브라우저가 받은 쿠키를 보존한다.
  4. 두 번째 연결에서 HTTP헤더에 쿠키를 싣어서 서버에 request한다.
  5. 서버는 받은 쿠키로부터 클라이언트를 판별한다.

쿠키에는 다음과 같은 제약조건이 존재합니다.

  • 클라이언트는 총 300개의 쿠키를 저장할 수 있음
  • 하나의 도메인 당 20개의 쿠키를 가질 수 있음
  • 하나의 쿠키는 4096byte까지 저장 가능

하나의 도메인에서 설정한 20개의 쿠키의 갯수가 20개가 넘으면 가장 적게 사용되는 쿠키부터 삭제됩니다.

이러한 쿠키는 텍스트 형식으로 저장되며 쿠키가 사라지는 시점은 쿠키를 저장할 때 설정할 수 있고 만약 설정하지 않으면 해당 브라우저 종료시 삭제됩니다.

또한 쿠키에는 단점이 존재하는데 사용자의 데이터가 컴퓨터에 저장된다는 보안적인 문제가 존재합니다. 또한 악성유저들은 이러한 정보를 악용하는 경우도 있습니다.


세션

세션은 클라이언트와 서버의 통신 상태를 가집니다. 세션을 이용한 다수의 HTTP통신을 하나의 묶음으로 “세션관리”라고 말합니다. 세션관리에서는 세션ID라는 것과 세션을 하나의 짝으로 취급하는데, 이때 세션ID만이 클라이언트에 보내집니다. 클라이언트에 세션ID를 전해주는 방법은 여러가지가 있으니 일반적으로 쿠키를 이용하는 경우가 많습니다. 클라이언트로부터 세션 ID를 받아 실제로 서버의 세션에 저장된 중요한 정보들과 관련을 짓기때문에 쿠키만을 이용한 방식보다 보안적인 측면에서 좋습니다.



다수의 서버를 이용하는 경우에는 로그인한 시점에서 사용이 끝날때까지 한가지 서버만을 이용하게 하던지, 혹은 서버에 저장되는 세션정보를 전부 다 동기화를 해야합니다. 

캐시

Cache란 웹페이지 Resource 파일들 (오디오, 비디오, 이미지 등)의 임시 저장소로 다음에 같은 웹페이지 (또는 웹사이트) 접속 시 페이지 로딩 속도를 개선해주는 역할을 합니다. 

'' 카테고리의 다른 글

CORS  (0) 2017.03.17
세션 클러스터링  (0) 2016.11.09
HTML5  (0) 2016.07.28
웹서버와 WAS  (0) 2016.06.28
RestFul API  (0) 2016.06.20
세션, 쿠키, 캐시  (0) 2016.05.21

+ Recent posts