1. 웹을 지탱하는 기술 3가지를 쓰고 그 관계를 설명하시오. (27~28p)
   -HTTP, URI, HTML. HTTP는 URI로 조작대상을 지정하고, HTML의 링크는 URI를 이용한다. HTML은 HTTP로 통신을한다.
2. 웹 이전의 하이퍼미디어, 분산 시스템과 비교하는 관점에서 하이퍼미디어로서의 웹, 분산시스템의로서의 웹을 설명하시오. (42~43p)
   -인터넷을 이용하기 때문에 불특정 다수의 정보를 서로 링크시킬 수 있고, 시트템을 대규모화하기 쉬받는 중요한 이점을 가지고 있었다. 반면, 정보의 집중적인 관리가 어려워지고 링크가 끊어지기 쉽다는 결점도 가지고 있다. 분산형은 미리 상정한 숫자와 종류의 클라이언트를 상대로 서비스를 제공하는 시스템이고 개방된 네트워크 환경에서 불특정 다수의 클라이언트에 대해 서비스를 제공하는 시스템으로는 어울리지 않다.
3. 웹 2.0에선 매쉬업이 중요했다. 매쉬업은 무엇인지 설명하고 이러한 흐름 속에서 REST가 승리한 요인은 무엇인가? (51~52p)
   -여러가지 웹 APU가 제공하는 정보를 조합하여 하나의 애플리케이션을 실현하는 방법이다.
4. 아키텍쳐 스타일이란 무엇인가? (54p)
   -아키텍처 패턴이라고도 하고, 복수의 아키택처의 공통된 성질, 양식, 규정 혹은 독특한 방식을 가리키는 말이다.
5. 리소스란 무엇인가? (58p)
   -리소스는 웹상에 존자하는 이름을 가진 모든 정보다. 리소스의 이름은 어떤 리소스를 다른 리소스와 구별하기 위한 것이다. 그게 URI이다.
6. URI란 무엇인가? 또한 URI가 가진 Addressability에 대해서 설명하시오. (58~60p)
   -리소스의 이름이다. 리소스란 웹상의 정보이다. 전세계의 무수한 리소스는 각각 URI로 의미 있는 이름을 가진다. URI를 이용함으로써, 프로그램은 리소스가 표현하는 정보에 접근할 수 있다. 이 UURI 가 지니고 있는 리소스를 간단히 가리킬 수 있는 성질을 가리켜 어드레스 가능성 이라고 부른다.
7. 서버와 클라이언트 사이에 주고받는 어떤 구체적인 데이터를 무엇이라 하는가? (61p)
   -RESOURCE REPRESENTATION. 하나의 리소스는 복수의 표현을 가질수 있다. 리소스는 상태라는 것이 있는데 시간의 경과에 따라 리소스의 상태가 변하면 그 표현도 변한다.
8. REST는 복수의 아키텍처 스타일을 조합하여 구축한 복합 아키텍처 스타일이다. 6가지 아키텍처 스타일을 모두 나열하고 각 아키텍처 스타일이 주는 장점을 차례대로 모두 설명하시오. (62~69p)
   -스테이트레스 서버: 서버가 상태를 가지지 않으므로써 서버 측의 구현을 간략화 할 수 있다.
   클라이언트/서버: 웹은 HTTP라는 프로토콜을 이용해 클라이언트와 서버가 서로 통신하는 클라이언트/서버의 아키텍처 스타일을 쓰고 있다. 클라이언트가 서버에 요청을 보내면, 서버는 클라잉너트에 대해 응답을 돌려준다. 이것으로 클라이언트와 서버로 분리해서 처리할 수 있다.다른 플래트폼으로 접속을 할 수 있게 되고 복수 서버를 조합해 확장을 할 수 있다.
   캐시: 리소스의 신선도에 기초해, 한번 가져온 리소스를 클라이언트 쪽에서 돌려 쓰는 방식이다. 네트워크 대역의 이용과 처리시간을 축소하고 더욱 효율적으로 처리할 수 있다.
   유니폼 인터페이스: URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키첵처 스타일이다. 유연성에 제약을 가함으로써 전체적인 아키텍처가 간결해진다.
   계층화 시스템: 시스템을 몇개의 계층으로 분리하는것. 이것으로 관심사의 분리및 재활용 용이 등의 이점을 가진다.
   코드 온 디맨드: 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일이다. 클라이언트를 차후에 확장할 수 있다는 장점이 있다.
9. REST의 근간을 이루는 사상인 접속성(Connectedness) 이란 무엇인가? (72p)
   -리소스를 링크로 연결하여 하나의 애플리케이션을 구성한다는 개념이다.
10. 기존 분산 시스템의 문제점과 이에 비해 REST가 갖는 장점들은 무엇인가? (72~73p)
    -REST에 기초한 웹 서비스에서는 링크를 이용하여 애플리케이션을 실현한다. 링크를 따라 애플리케이션의 상태를 변화시키는 편이 전체적인 성능 저하를 억제할 수 있다.
    REST에 기초한 웹에서는 유니폼 인터페이스에 의해 인터페이스가 고정되어 있기 때문에 호환성 문제는 발생하지 않는다.
11. http://yohei:pass@blog.example.com:8000/search?q=test&debug=true#n10과 같은 URI에서 각 7개의 구성요소를 구분하여 쓰시오. (79p)
    -URI SCHEME: HTTP
    사용자 정보: YOHEI:PASS
    호스트명: BLOG.EXAMPLE.COM
    포트: 8000
    패스: /SEARCH
    쿼리 파라키터: Q=TEST&DEBUG=TRUE
    URI 프래그먼트: #N10
12. 시작점이 /foo/bar/ 일 때 상대 경로 ../hoge/fuga의 절대 경로를 쓰시오. (81p)
    -..FOO/HOGE/FUGA
13. URL 구현에서 주의할 점 2가지를 모두 설명하시오. (89p)
    -가능한 절대 URI를 사용하고 %인코딩의 문자 인코딩으로 될수 있는한 UTF-8로 이용할것.
14. URI, URL, URN이 무엇인지 각각 쓰시오. (90~91p)
    -URI-UNIFORM RESOURCE IDENTIFIER 리소스 식별자
    URL -UNIFORM RESORCE LOCATOR 리소스 위치 식별
    URN -UNIFORM RESOURCE NAME 리소스 이름 식별
15. Cool URI가 무엇인지 설명하고 이를 위한한 URI 설계지침 5가지를 모두 설명하시오. (92~98p)
    -URI는 변하지 않아야 한다. 변하지 않는 URI야 말로 최고의 URI 이다.
    URI 설계지침5가지
    URI에 프로그래밍 언어에 의존적인 확장자를 이용하지 않는다.
    의존적인 경로명, 프로그래밍 언어의 메서드명, 세션ID를 사용하지 않고 URI는 해당 리소스를 표현하는 명사이다.
16. URI의 불투명성에 대해서 아는대로 설명하시오. (107~108p)
    -URI를 클라이언트 쪽에서 구성하거나 확장자로 리소스의 내용을 추단하거나 할 수 없는 특징.
17. 웹 서비스와 웹 API 설계에 있어서 URI가 중요한 이유 3가지는 무엇인가? (109p)
    -URI는 리소스의 이름이고, 수명이 길고, 브라우저가 어드레스 란에 표시한다.
18. HTTP 메시지 구조를 그리고 각각에 대해서 설명하시오. (123~128p)
    -요청메시지와 응답 메시지. STARTLINE/HEADER/빈줄/바디. 스타트라인은 요청 혹은 STATUS 라인 요청이냐 응답이냐에 따라 갈리고 요청일시 HTTP 메서드가 들어간다. 응답일 경우 요청 결과를 보내준다. 헤더는 메시지의 메타 데이터이다. 빈줄은 빈줄이다. 바디는 그 메시지를 나타내는 본질적인 정보가 들어가있다.
19. 애플리케이션 상태란 무엇인가? 그리고 Stateful 서버의 결점은 무엇인가? (131~132p)
    -세션 상태이다. 일련의 조작 중의 상태는 애플리케이션 상태를 말한는것이다.
20. Self Descriptive Message가 무엇인지 설명하고 이를 이용한 Stateless 서버의 장점을 쓰시오. (132~134p)
    -스테이트리스 서버는 상태를 저장 하지 않기 때문에 요청을 처리하는 데 필요한 정보가 모두 포함되어 있는 메시지를 가리켜 자기 기술적 메시지를 받는다. 장점은 위에 말했듯이 서버 구현이 심플해진다. 확장도 쉽고, 어느 서버로 보내도 된다.
21. Stateless 서버의 단점은 무엇인가? (134~136p)
    -송신할 데이터의 양이 많아진다. 인증등 서버에 부하가 걸리는 처리를 반복한다.
22. POST의 용도 3가지를 설명하시오. (141~145p)
    -리소스의 작성, 데이터 추가, 다른 메서드 대응할 수 없는 처리의 실행.
23. 리소스 작성시 POST와 PUT 중에 POST를 쓰는게 적절한 이유는 무엇인가? (149p)
    -post로 리소스를 작성할 경우 클라이언트는 리소스의 uri를 지정할 수 없다. uri의 결정권은 서버 측에 있다. 반대로 PUT으로 리소스를 작성 할경우, 리소스의 URI는 클라이언트가 결정한다. 리소스의 작성은 POST로 수행하여 URI를 서버 측에서 결정하는 설계가 바람직하다.
24. HEAD의 사용 용도는 무엇인가? (151p)
    -리소스의 헤더 만을 취득해서 바드를 받지 않음으로 네트워크의 대역을 절약하면서 리소스의 크기를 조사하거나, 리소스의 갱신인자를 구할 수 있다.

25. 다음 요청과 응답의 의미는 각각 무엇인가? (152p)

    요청
    OPTIONS /list/item1 HTTP/1.1
    Host: Example.com

응답 HTTP/1.1 200 OK Allow: GET, HEAD, PUT, DELETE

-리소스가 지원하고 있는 메서드의 목록을 반환 받음.

5. 멱등성, 안전에 대해서 각각 설명하시오. (157p)  
-멱등석은 어떤 조작을 몇번을 반복해도 결과가 동일한것. 안전은 조작 대상의 리소스의 상태를 변화시키지 않는 것.

6. 멱등성과 안전을 기준으로 GET, HEAD, PUT, DELETE, POST를 분류하시오. (158p)  
-GET, HEAD: 멱등+안전  
PUT, DELETE: 멱등 
POST: 둘다 아님.

7. GET을 바르게 이용하고 있는지 판단하는 기준은 무엇인가? (164p)  
-리소스 취득 외에 하는것을 하면 잘못 쓰고 있다.

8. 현재 토마토 가격은 100원이다. PUT으로 토마토 가격을 갱신할 때 다음 PUT 사용은 어떤 부분이 잘못됐는가? 또한 올바른 표현은 무엇인가? (165~167p)  
```html
PUT /tomato HTTP/1.1
Host: example.com
Content-Type: text/plain; charset=utf-8

+50

-+50을 150 으로 바꿔 주면 된다.

9. 스테이터스 코드 1xx, 2xx, 3xx, 4xx, 5xx의 분류와 의미를 설명하시오. (173~174p)
   -1: 처리중. 처리가 계속되고 있음을 나타낸다.
   2: 요청이 성공했다고 나타낸다.
   3: 리다이렉트, 다른 리소스로의 리다이렉트를 나타낸다.
   4: 클라이언트에 에러를 나타낸다.
   5: 서버에러를 나타낸다.
10. 스테이터스 코드에서 첫 번째 숫자를 이용한 분류 방식의 장점을 모두 설명하시오. (174~175p)
    -그 숫자를 보고 서버가 어떤 응답을 보낸 것인지 이해할 수 있으며, 클라이언트 측에서 어떻게 처리해야 할지 대략 알 수 있게 된다. 그리고 클라이언트는 처음 숫자만 보고 최소한의 처리가 가능해진다.

11. 다음 응답 코드의 문제점은 무엇인가? (189p)

    HTTP/1.1 200 OK
    Content-Type: application/xml

12. HTTP에서 기술되는 일시는 어떤 표준시를 따르는가? (196p)
    -GMT
13. UTF-8로 선언된 xml 문서의 경우 Content-Type 헤더에 들어갈 알맞은 값은 무엇인가? (200~201p)
    -application/xml; charset=utf-8
14. Content Negotiation이란 무엇인가? (202p)
    -웹 브라우저의 리소스를 띄울때 클라이언트와 교섭해서 지정 리소스의 언어를 결정하는것.

15. 다음 2개의 메시지에 있는 10은 각각 몇 바이트인가? (205~206p)

    Content-Length: 10
    Transfer-Encoding: chunked
    Content-Type: Text/plain; charset=utf-8
    10
    The brow fox ju

    -10, 16

16. WWW-Authenticate: Basic realm=“Example.com 를 클라이언트 입장에서 해석하시오. (207~208p)
    -WWW-Authenticate: 헤더에 의해 클라이언트는 서버가 제공하는 인증방식. Basic: basic인증을 지원. realm: 서버상에서 이 리소스가 속한uri 공간 Example.com: uri공간이름
17. URI Space를 설정하는 이유는 무엇인가? (208p)
    -동일한 uri 공간에 속한 리소스에는 같은 정보를 송신할 수 있다고 가정하게 되어 있어 요청을 보낼 때마다 매번 401 반환하는것을 피하기 위해서.
18. SSL/TLS에서 제공하는 3가지 기능에 대해서 설명하시오. (211p)
    -암호화: 공통키 암호에 기반한 암호화 기능
    인증: 공개키 증명서에 기반한 인증 기능
    변경 감지: 해시 공통키에 기반한 변경 감지 기능
19. Expires와 Cache-Control의 유효기간 표시법 차이는 무엇인가? (221p)
    -expire은 pragrma: no-cache혹은 특정 gmt날짜 까지.
    cache-control은 no-cache 혹은 max-age
20. 조건부 GET If-Modified-Since 와 If-None-Match 은 어떻게 구분하여 사용하는가? (226p)
    -ETag 해더를 사용해서 구분한다
21. Pipelining이란 무엇인가? (227p)
    -지속적 접속에서는 클라이언트가 응답을 기다리지 않고 같은 서버에 요청을 송신하게 하는 기능.
22. HTML이란 무엇인가? (232p)
    -HTML은 Hypertext Markup Language의 줄임말이다. 마크업 언어는 태그로 문서의 구조를 표현하는 컴퓨터 언어이다. 마크업 구조를 가진 문서를 가리켜 구조화 문서라고 한다.
23. 다음 문자 <, >의 실제 참조를 쓰시오. (239p)
    -< >
24. 복수의 XML 포맷을 조합할 때 이름의 충돌을 방지할 목적으로 사용하는 것은 무엇인가? 그리고 선언하는 서식은 무엇인가? (241p)
    -namespace, xmlns:접두어=“이름공간명”

25. 다음 문서 URI는 http://example.com/test.html이다.

    을 가리키는 URI를 작성하시오. (251p)

    <h1 id="title">첫 번째 HTML</h1>

    -http://example.com/test.html#title

26. <a> <link>에 있는 rel 속성의 의미는 무엇인가? (257p)
    -링크하는 쪽과 링크되는 쪽의 리소스가 어떤 관계에 있는지 기술한다. 링크 관계라고 부르기도 한다.
27. 웹 서비스에서 JSON을 활용하는 이점은 무엇인가? (340p)
    -JavaScript의 기법으로 데이터를 기술할 수 있는 점이 가장 큰 특징이다. 호환성이 좋고 xml과 비교하면 데이터 표현이 간결하다는 이점이 있다.
28. 크로스 도메인 통신 제한에 대해서 설명하고 이를 극복하는 2가지 해결법을 쓰시오. (348~350p)
    -단일 도메인과만 통신해야 한다는 제한이다. script 요소를 복수로 사용하거나 jsonp를 쓰면된다. 아니면 CORS 를 쓰면 된다.
29. JSON을 하이퍼미디어 포맷으로 사용할 때 중요한 점은 무엇인가? (353p)
    -포맷으로 사용하기 위해서는 링크를 표현하는 맴버를 정확히 넣을 필요가 있다.
30. 리소스를 설계할 때 가장 중요한 점은 무엇인가? (357p)
31. 리소스를 설계란 클라이언트와 서버간의 인터페이스의 설계, 즉 웹 서비스와 웹 API의 외부설계이다. 어떻게 리소스를 분할하고, URI로 이름을 붙이고, 상호 링크를 가지게 할지가 리소스 설계의 핵심이 된다. 설계란 시스템을 어떤 구조로 어떻게 개발할 것인지를 검토하고, 그림이나 문서로 남기는 작업이다. 리소스의 설계도란, 리소스의 종류, 리소스의 표현, 리소스의 조작방법, 리소스와 리소스의 링크 관계 등을 말한다. 이 설계할때 중요한 점은 웹 서비스와 웹 API를 나눈어 생각하지 않는 것이다.
32. 리소스 지향 아키텍처의 설계 방법의 모든 단계를 설명하시오. (358p)
33. - 웹 서비스에서 제공할 데이터를 특정한다
    데이터를 리소스로 나눈다
    리소스에 URI로 이름을 부여한다
    클라이언트에 제공할 리소스의 표현을 설계한다
    링크와 폼을 이용해 리소스와 리소스를 연결한다
    이벤트의 표준적인 코스를 검토한다
    에러에 대한 검토한다
34. 리소스 지향 아키텍처의 4가지 특성은 무엇인가? 그리고 그 우선순위는? (360~361p)
35. - 순서대로
    어드레스 가능성: URI만 있으면 리소스를 한결같이 가리킬 수 있다는 성질
    접속성: 리소스를 링크로 접속하여 하나의 애플리케이션을 이룬다는 성질
    유니폼 인터페이스: 리소스가 어드레스 가능하며 또한 올바로 접속되어 있는 상태가 있고서야 비로소 가치가 생기는 성질.
    스테이트리스성: cookie 세션등 때문에 그다지 중요하지 않다.
36. 리소스 작성에 POST 대신 PUT으로 작성한 경우의 장점과 단점을 모두 설명하시오. (397p)
    -post를 지원할 필요가 없어지기 때문에 서버측의 구현이 간단해진다. 클라이언트가 작성과 변경을 구별할 필요가 없어도 되므로 클라이언트 측의 구현이 간단해진다. 단점은 클라이언트가 URI 구조를 미리 알아야 한다. 요청의 외관상으로는 그 조작이 신규 작성인지 갱신인지 구별할 수 없다.
37. Bulk Update에 대해서 설명하고 장점과 단점을 설명하시오. (399p)
    -리소스를 전체를 송신하는 방법이다. 이것으로 클라이언트의 구현이 간단해지는 반면, 전송할 데이터가 커진다는 결점이 있다.
38. 트랜잭션에 대하여 설명하시오. (406p)
    -한쪽만 처리됬거나 문제가 발생시 양쪽 모두 원래대로 돌아간다는 것을 보증하는 것이다.
39. RESTful한 설계를 지키려면 HTTP의 유니폼 인터페이스로 구현할 수 없는 처리를 만났을 때 어떻게 해야되는가? (407p)
    -HTTP의 유니폼 인터페이스로 구현할 수 없는 처리를 만났을때는 새로운 리소스를 도입해 해결을 꾀하는 것이 RESTful한 설계의 정석이다.
40. 베타제어란 무엇인가? (413p)
    -복수의 클라이언트가 동시에 하나의 리소스를 편집해 경합이 일어나지 않도록 하나의 클라이언트만 편집하도록 제어하는 처리를 말한다.
41. 비관적 잠금과 낙관적 잠금에 대해서 각각 설명하시오. (415~426p)
    -비관적 잠금은 사용자를 신용하지 못하고 경합이 발생하지 않도록 하는 제어다. lock 요청후 토큰을 돌려줘서 그 클라이언트만 리소스를 수정 할 수 있도록 권한을 주고 그 사이에 다른 클라이언트가 수정 할려고 했을때는 거부하는 것이다. 끝날때쯤은 unlock를 돌려줘서 권한을 푼다. 낙관적은 잠기지 않고 경합이 일어났을때 대처하는 구조이다. ETag로 관리를 한다. 리소스에 대한 etag를 돌려줘서 수정 할때마다 ETag를 바꾼다.
42. 낙관적 잠금에서 Precondition Failed가 발생한 경우 3가지 대처법은 무엇인가? (428~429p)
    -경합을 이르킨 사용자에게 확인한 후, 갱신 또는 삭제를 하거나 리소스를 보존하거나 사용자에게 변경점을 전하고, 병합을 촉구한다.
43. 웹 서비스에서 제공할 데이터를 특정하고, 데이터를 리소스로 나누는 방법 3가지는 무엇인가? (432p)
    -관계 모델 ER 다이어그램, 객체 지향 모델의 클래스 다이어그램, 정보 아키텍쳐.
44. 리소스 설계에서 굳이 정규화를 무너뜨리는 이유는 무엇인가? (435p)
    -리소스의 설계에서는 하나하나의 리소스를 그 자체로 모든것을 표현할 수 있도록 자기 기술적으로 만들기 위해 정규화를 무너뜨린다.
45. 객체지향 모델에서 리소스를 도출할 때 중요한 것은 무엇인가? (442p)
    -클래스가 가진 메서드를 조작결과 리스트로 변환하는 것이다.
46. 리소스를 설계할 때 가장 중요한 사고방식은? (449p)
    -웹 서비스와 웹 API를 구분해서 생각 하지 않는것.