웹을 지탱하는 기술 - 야마모토 요헤이

1. 웹 개론

 - 웹의 근간 기술:  HTTP, HTML, URI 로 이루어지며 각 HTML간 링크로 연결, 분산시스템

 단점으로는 링크가 끊어지기 쉽다는 점, 단방향 링크라는점

 - REST: 하나의 web architecture style을 가리키는 용어이머 클라이언트-서버에서 파생된 아키텍쳐.  각 분산된 서버에 존재하는 리소스들을 URI로 표현하고 이를 HTTP 프로토콜로 클라이언트와 서버가 리소스를 주고받는 아키텍쳐가 기본.

stateless: REST의 중요한 핵심 개념중 하나. 서버에서 클라이언트의 상태를 관리하지 않는 다는 것을 의미. 서버측의 구현을 간략히 할 수있다는 장점 존재. 하지만 현실적으로 이미 cookie나 session등의 기법으로 클라이언트의 상태를 관리하는 사용양태 대다수. 

즉 REST = client+stateless+cache+uniform interface+ layer system+ code on demand(서버에서 자바스크립트 등 필요한 코드 다운받아서 사용)

2. URI

 - URI 설계(RFC 3986 참조) : A-Za-z0-9-.~:@!$&'() 사용가능. 이외의 문자를 사용하기 위해서 %인코딩(UTF-8 문자를 구성하는 각 바이트를 %xx x는 16진수)으로 문자 인코딩. 

예를 들어 example.com/가 는 실제로 브라우저창에서는 저렇게 보이지만 서버-브라우저 사이에서 전송될때는 example.com/%EA%B0%80으로 전송됨

가능한 URI는 안변하는게 좋음. 만약 변할경우 리다이렉트(301 Moved permanantly) 페이지 정도는 띄워주는것이 웹상의 관례. 또한 URI 지정시 프로그래밍 언어와 구현에 종속되지 않도록 설계가 필요.  URI는 동사가 아니라 명사임.  URI 자체만으로 리소스의 성질을 표현할 수 있도록 투명하게 설계하여야 함

3. HTTP

<HTTP message structure>

Start Line

Header

blank Link

Body

 - HTTP의 stateless : 매번 전 요청-응답 상태를 기억하지 않기때문에 요청이 길어질 수 있다. (FTP는 상태를 기억함). 대신에 클라이언트 수가 늘어나도 인터페이스나 구현의 변화가 없다는 장점이 있다.  대신에 모든 메시지가 self-descriptive message화 되어서 필요한 모든 정보를 표기해야 한다. 또한 중간 통신오류나 에러 발생 시 이를 복구하기가 쉽지 않다. 

 - methods : GET(read),POST(create),PUT(update),DELETE,HEAD,OPTIONS,TRACE,CONNECT 의 8개 메서드 존재

특히 POST는 다른 메서드가 처리할 수 없는 처리에 많이 활용 된다. 

If-Modified-Since 헤더와 함께 사용해서 지정한 시간 이후 변경사항이 있으면 GET 하는 조건부 요청이 가능하다.

멱등성(idempotence)란 어떤 조작을 반복해도 결과가 항상 동일한 성질을 의미하는데, GET,PUT,DELETE는 멱등성이 보장되나 POST는 멱등하지도 안전하지도 않음. (예를들어 쇼핑몰에서 주문완료후 뒤로가기를 누르면 다시 주문을 재전송할 위험 존재. 멱등하지 않기 때문에)

오용사례: 각 메소드의 정의를 무시하고 사용- get을 리소스 삭제 목적으로 사용할 경우, 이런경우 GET의 원래 성질인 안전성 보장 못함

 - status code : 1xx(처리중), 2xx(성공), 3xx(리다이렉트), 4xx(클라이언트 에러), 5xx(서버에러)

 - header : 캐쉬관련, 바디에 대한 메타 데이터, 메시지 동작 결정, 인증등의 구현과 관련. 애초에 email의 스펙(RFC 822)를 빌려서 사용하였기 때문에 상당부분 email의 header와 공통인 부분 많음. 

4. Hypermedia format

 - HTML

 - microforms

 - atom

 - json

5. 웹 서비스 실제 설계

 - resource 설계란

 - 설계 스킬

 - 트랜잭션 처리, 배타제어: WebDAV

http 헤더가 포함하는 정보(http 1.1)

서버정보

date, 

retry-after, 

server(서버 소프트웨어정보), 

set-cookie(서버측에서 클라이언트에 생성하는 쿠키 정보), 

클라이언트 정보

cookie, 

expect(클라이언트가 기대하는 서버의 동작), 

referer(브라우저에서 링크를 클릭했을때 클릭한 쪽의 URI), 

user-agent(클라이언트의 소프트웨어 정보(주로브라우저))

리소스 정보

content-encoding(컨텐츠 body의 압축방식), 

content-language(컨텐츠의 국가언어), 

content-length, 

content-MD5(손실 검출), 

content-type(컨텐츠 body의 미디어 타입:xml,json..etc), 

content-location(요청에서 지정한 URI외 다른 URI를 통해서도 해당 리소스를 취득할 수 있을때 이를 표시), 

last-modified(해당 리소스의 최종 갱신일), 

location(리다이렉트 또는 이동할 URI 또는 신규작성시의 URI), 

host(요청한 URI의 호스트명과 포트번호를 나타냅니다)

컨텐츠 네고시에이션

accept(클라이언트(me)가 이해할 수 있는 미디어 타입을 서버에 알려줌),

accept-charset(클라이언트가 이해할 수 있는 언어 인코딩 지정),

accept-encoding(클라이언트가 이해할 수 있는 압축방식 지정),

accept-language(클라이언트가 이해할 수 있는 자연언어 지정),

vary(서버입장에서 클라이언트에게 자신이 컨텐츠 네고시에이션을 수행할 수 있는 헤더 목록을 보여줌 vary : * 는 콘텐츠 네고시에이션이 이루어졌지만 응답을 캐시해서는 안된다는 의미)

조건부 요청

Etag(서버입장에서 리소스가 변화했는지 여부를 나타내는 fingerprint),

If-non-match(etag와 연계되어서 클라이언트가 해당 리소스의 etag가 일치하지않을때 리소스를 get할 것임을 명시)

If-modified-since(제시한 일시 이후로 만약 리소스가 갱신되었으면 get 할것임을 명시)

If-match,

If-ummodified-since,

부분적 get

Range(클라이언트가 바이트로 가져올 리소스 크기 지정)

If-range,

Accept-range(요청한 리소스가 부분적 get이 가능한 리소스인지를 명시),

content-range(부분적 get으로 가져온 리소스가 전체 body의 어느부분에 해당하는지 바이트로 표시),

캐시

Pragma(이 리소스는 캐시불가 임을 명시),

cache-control(클라이언트와 서버가 따라야하는 캐시 방법 명시),

expires,

age,

인증

WWW-authenticate(서버가 지원하는 인증 방식 명시),

authorization(인증 시에 인증 정보를 제시),

proxy-authenicate(프록시가 지원하는 인증 방식 명시),

proxy-authorization(프록시 인증시 인증 정보 제시),

x-wsse

청크 전송

transfer-encoding,

trailer(청크 전송시 포험되어있는 헤더 종류 표시),

TE(클라이언트입장에서 내가 인식하는 transfer-encdoing헤더 지정)

기타

allow(리소스가 지원하는 메서드의 리스트),

connection(이 뒤에 tcp 접속 close 의미),

max-forwards(중계 서버사용시 , 몇번 더 전송할 수 있는지를 의미),

upgrade(통신 프로토콜 변경을 의미하지만 현재 HTTP 1.1보다 나은 프로토콜이 없으므로 무효),

via(서버-클라이언트 사이 프록시 등 중계자가 있을경우 각각의 호스트명과 프로토콜 버전 기록),

warning,

content-disposition,

slug,

x-http-override