1-1. URI : URI를 사용하면 웹상에 존재하는 모든 리소스를 한결같은 방식으로 보여줄 수 있습니다.
인터넷 상에서 반드시 유일한 호스트명의 구조와 호스트 내에서 유일한 계층적인 경로를 결합함으로써, 어떤 리소스의 URI가 전 세계의 다른 리소스와 절대로 중복되지 않도록 되어 있습니다.
* URN : 리소스의 이름을 나타내는 것 :리소스에 도메인명과는 독립된 이름을 붙일 수 있습니다. 예를 들어, 서적은 ISBN이라는 세계적으로 통일된 ID를 가지고 있습니다. URL과 같이 서버명과 프로토콜명이 들어있지 않기 때문에 URI로서 리소스를 가져 올 수 없다.
* URL : 리소스의 위치를 나타내는 것
* 리소스 : 웹상에 존재하는 이름을 가진 모든 정보.
리소스의 이름은 어떤 리소스를 다른 리소스와 구별하기 위한 것이고 즉 URI를 말합니다. 리소스들은 URI로 식별할 수 있습니다.전 세계의 무수한 리소스는 각각 URI로 의미 있는 이름을 가진다. URI를 이용함으로써, 프로그램은 리소스가 표현하는 정보에 접근할 수 있다.서버와 클라이언트 간에 실제로 리소스를 주고받을 때는 어떤 구체적인 데이터를 서로 송신합니다.
* 어드레스 가능성 : URI가 지니고 있는 리소스를 간단히 가리킬 수 있는 성질을 가리킴. 리소스를 어드레스 가능한 상태, 즉 제대로 이름이 붙어 있고 적절한 수단으로 접근할 수 있는 상태로 만들면, 프로그램을 만들기가 아주 쉬워집니다.
Cool URI : 변하지 않는 URI야말로 최고의 URI이다.
구현 의존성을 배제하고 심플하게 만들면 사용성이 향상된다. 기억하기도 간단하고, 개발자가 아닌 보통사람들도 사용하기 쉽다.
- 프로그래밍 언어에 의존적인 확장자와 경로를 포함하지 않는다.(.pl,rb,.do,.jsd 등)
- 메서드명과 세션ID를 포함하지 않는다.(jsessionid=123456)
- URI는 리소스를 표현하는 명사로 한다 (/show/123)
- 구현에 의존적인 경로명을 사용하지 않는다.(cgi-bin, servlet 등)
- URI를 변경하고 싶으면 가능한 한 Redirect하도록 합시다.
1-2. HTTP : 웹의 기반이 되는 프로토콜
HTTP : 이름대로라면 하이퍼텍스트 전송용 프로토콜이지만, 실제로는 HTML과 XML같은 하이퍼텍스트뿐만 아니라, 이미지, 음성, 동영상, JavaScript 프로그램,PDF와 같은 각종 오피스 도큐먼트 파일 등 컴퓨터에서 다룰 수 있는 데이터라면 무엇이든 전송할 수 있습니다.
웹은 HTTP라는 프로토콜을 이용해 클라이언트와 서버가 서로 통신하는 클라이언트/서버의 아키텍처 스타일을 채용하고 있습니다. 즉, 클라이언트가 서버에 요청Request을 보내면 서버는 클라이언트에 대해 응답을 돌려줍니다.
* TCP/IP : 인터넷의 토대를 구성하는 중요한 네트워크 프로토콜입니다. HTTP는 TCP/IP를 기반으로 하고 있습니다.인터넷의 네트워크 프로토콜은 계층 구조를 가지고 있습니다.각 계층별로 추상화하여 구현하면, 물리적으로 케이블이 동선인지 광케이블인지 하는 하위 계층의 구체적인 사항에 좌우되지 않고, 상위 계층을 구현할 수 있습니다.
- 네트워크 인터페이스 계층(이더넷) : 가장 아래의 계층으로 물리적인 케이블이나 네트워크 어댑터에 해당하는 부분입니다.
- 인터넷계층(IP) : 네트워크에서 데이터를 실제로 주고받는 것입니다. IP가 여기 해당합니다. IPㅇ서는 데이터의 기본적인 통신단위를 패킷이라고 부릅니다. 지정한 IP어드레스와 패킷 단위로 데이터를 주고받으면서 통신합니다.
- 트랜스포트(전송) 계층(UDP, TCP) : TCP가 여기 해당합니다. TCP는 목적지의 상대에 대해서 커넥션을 연결합니다. 이 커넥션을 사용해 데이터의 누락을 체크하고, 데이터의 도달을 보증합니다.
- 애플리케이션(응용) 계층(HTTP,NTP,SSH,SMTP,DNS) : TCP로 프로그램을 만들 때는 소켓이라고 불리는 라이브러리를 사용하는 것이 일반적입니다. 소켓은 네트워크에서의 데이터 교환을 추상화한 API로 접속,송신,수신,절단 등의 기본적인 기능을 갖추고 있습니다. HTTP서버와 브라우저는 소켓을 이용하여 구현합니다.
HTTP의 구체적인 구조
웹은 아키텍처 스타일로 클라이언트/서버를 채용하고 있습니다. 즉 웹브라우저가 정보를 제공하는 웹서버에 접속하여 각종 요청을 보내고 응답을 받는 구조입니다.
HTTP가 동기형 프로토콜이기 때문에 서버에서의 처리에 시간이 많이 걸리는 경우라도 요청을 보낸 클라이언트는 응답이 돌아올 때까지 대기합니다. 클라이언트는 우선 DNS를 사용해 호스트 이름을 해석하고, 그 결과로 얻어진 IP어드레스의 TCP 80번 포트에 접속한후 요청을 전송합니다. 서버는 이 요청을 읽어 들여 해석하고 응답을 보냅니다.
- 클라이언트에서 일어나는 일들 : 1.요청 메시지 구축 2.요청 메시지 송신 3.(응답이 돌아올 때까지 대기) 4.응답 메시지 수신 5.응답메시지 해석 6.클라이언트의 목적을 달성하기 위해 필요한 처리
- 서버에서 일어나는 일들 : 1.(요청을 대기) 2.요청 메시지 수신 3.요청 메시지 해석 4.적절한 애플리케이션 프로그램으로 처리를 위임 5. 애플리케이션 프로그램으로부터 결과를 취득 6.응답 메시지 구축 7.응답 메시지 송신
HTTP메시지의 구성요소 (스타트 라인, 헤더, 빈 줄 , 바디)
요청메시지 (1.요청라인-메서드,요청URI,프로토콜버전으로 구성 2.헤더-메시지의 메타 데이터, 각 헤더는 이름:값의 구성 3.바디-메시지를 나타내는 본질적인 정보,리소스를 새로 작성하거나 갱신할 때는 요청의 바디부분에 리소스의 표현자체)
응답메시지 (1.스테이터스 라인-프로토콜버전,스테이터스 코드,텍스트구문으로 구성 2.헤더- HTML의 MIME미디어 타입과 그 문자 인코딩 방식을 지정 3.바디)
*메타 데이터 : 데이터를 기술하는 데이터, 데이터에 대한 데이터를 말합니다. 메타라는 것은 이렇게 어떤 대상에 대해 고차원 것을 나타내는 접두어입니다.
HTTP의 스테이트리스성
스테이트풀의 결점 : 서버가 클라이언트의 애플리케이션 상태를 기억하는 것은 클라이언트의 수가 증가함에 따라 어려워지게 됩니다.
스테이트리스의 이점 : 스테이트리스는 클라이언트가 요청 메시지에 필요한 정보를 모두 포함시킵니다. 스테이트리스한 서버는 애플리케이션 상태를 기억할 필요가 없기 때문에 서버 시스템이 단순해집니다. 이 특성을 이용하면 확장시키는 것이 간단해집니다.
스테이트리스의 결점 : 1. 퍼포먼스 저하(클라이언트의 송신할 데이터 양이 많아지고 인증 등 서버에 부하가 걸리는 처리를 반복한다) 2. 통신에러에 대한 대처(네트워크 트러블이 발생했을 때 그 요청이 처리되었는지 알 수 없습니다)
* 스트레이트리스 : 서버가 클라이언트의 애플리케이션 상태를 보존하지 않는다는 제약
* 애플리케이션 상태 : 다른 이름으로 '세션상태'라고도 합니다. 시스템에 로그인하고부터 로그아웃할 때까지 일련의 조작을 모아'세션'이라고 부르는데, 이 일련의 조작 중의 상태는 애플리케이션 상태를 말하는 것이므로, 애플리케이션 상태와 세션 상태는 거의 동일한 의미가 됩니다.
HTTP메서드 - 8개 밖에 없는 메서드(GET,POST,PUT,DELETE,HEAD,OPTIONS,TRACE,CONNECT)
HTTP의 메서드를 한정하여 고정시켰기 때문에 결국 프로토콜이 심플하게 유지되었고, REST의 통일 인터페이스 제약으로 웹은 성공했습니다. GET의 숨겨진 안전성, PUT과 DELETE의 멱등성, 그리고 여차할 때는 뭐든지 할 수 있는 POST 각각의 메서드에 맞는 성질과 확장성을 갖춘 뛰어난 프로토콜입니다.
*GET : 리소드의 취득, 지정한 URI의 정보를 가져옵니다.
*POST : 리소스의 작성, 추가 1.서버 리소스의 작성(블로그 기사의 투고 등 조작에 사용) 2.리소스에 데이터 추가(로그등을 추가할 때) 3.다른 메서드로는 대응할 수 없는 처리(검색결과가 긴 경우 키워드를 요청 메시지의 바디에 넣는 경우)
* PUT : 리소스의 갱신,작성 1.리소스의 갱신(리소스의 텍스트를 바꿀때) 2.리소스의 작성(존재하지 않는 URI에 대한 요청)
- POST와 PUT의 사용 구분 : POST로 리소스를 작성할 경우, 클라이언트는 리소스의 URI를 지정할 수 없습니다. URI의 결정권은 서버 측에 있습니다. 반대로 PUT으로 작성하면 리소스의 URI는 클라이언트가 결정합니다. 예를 들어 Twitter와 같이 포스팅한 트윗의 URI를 서버 측이 자동적으로 결정하는 웹 서비스와 같은 경우는 POST를 이용하고, Wiki처럼 클라이언트가 결정한 타이틀이 그대로 URI가 되는 웹 서비스는 PUT을 사용하는 것이 적합합니다.
*DELETE : 리소스의 삭제
*HEAD : 리소스의 헤더(메타 데이터) 취득
*OPTIONS : 리소스가 서포트하는 메서드의 취득
- POST를 PUT/DELETE대신 사용하는 방법 1._method파라미터 2.X-HTTP-Method-Override
- 멱등성(어떤 조작을 몇번을 반복해도 결과가 동일한 것)과 안정성(조작 대상의 리소스의 상태를 변화시키지 않는 것
GET,HEAD(멱등이고 안전하다, PUT,DELETE(멱등이지만 안전하지도 않다) POST(멱등이지도 안전하지도 않다)
*CRUD : Create작성(POST/PUT), Read읽기(GET), Update갱신(PUT), Delete삭제(DELETE)라는 데이터 조작의 기본이 되는 4가지 처리
스테이터스 코드 - 요청의 결과로 얻어지는 응답메시지에서 그 의미를 전달한다.
클라이언트는 숫자를 보고 서버가 어떤 응답을 보낸 것인지 이해할 수 있으며, 클라이언트 측에서 어떻게 처리해야 할지 대략 알수 있게 됩니다. (1xx : 처리중 2xx : 성공 3xx : 리다이렉트 4xx : 클라이언트 에러 5xx : 서버 에러)
자주 사용되는 스테이터스 코드 9개(200 OK- 요청성공 201 Created-리소스 작성 성공 301 Moved Permanently-리소스의 항구적인 이동 303 See Other-다른 URI의 참조 400 Bad Request-요청 오류 401 Unauthorized-접근권한 없음, 인증실패 404 Not Found-리소스 없음 500 Internal Server Error-서버 내부 에러 503 Service Unavailable-서비스 정지
HTTP헤더 - 메시지의 바디에 대한 부가적인 정보, 즉 메타 데이터를 표현합니다. 클라이언트와 서버는 헤더를 보고 메시지에 대한 동작을 결정합니다. 미디어 타입과 언어 태그 등 프레임워크가 아닌 구현하는 사람이 구체적으로 설정해야만 하는 헤더도 많이 있습니다.
- 날짜 시간을 가지는 헤더, MIME 미디어 타입
캐시
캐시란, 서버로부터 가져온 리소스를 로컬 스토리지(하드디스크 등)에 저장하여 재사용하는 방법을 말합니다. 로컬 스토리지에 캐싱한 데이터 자체를 "캐시"라고 부르기도 합니다.
클라이언트가 저장한 캐시는 그 캐시의 유효 기간 내에 다시 그 리소스에 접근하려고 했을 때 재사용됩니다.
캐시용 헤더
클라이언트는 서버에서 가져온 리소스의 캐시 가능 여부를 조사하고 가능한 경우는 로컬 스토리지에 저장합니다. 어떤 리소스가 캐시 가능한지는 그 리소스를 취득했을 때의 헤더로 판단합니다. 리소스가 캐시 가능한지, 그 유효기간이 언제까지인지는 Pragma, Expire, Cache-Control 헤더를 이용해 서버가 지정합니다.
Pragma - 캐시를 억제한다
HTTP/1.1 200 OK
Content-Type: application/xhtmll+xml, charset=utf-8
Pragma:no-cache
Pragma 헤더에 지정할 수 있는 값은 공식적으로는 no-cache뿐입니다. 이 값은 리소스를 캐시하지 말 것을 나타냅니다. 클라이언트가 다음번에 이 리소스를 가져올 때는 반드시 서버에 다시 접속하지 않으면 안 됩니다.
Expires - 캐시의 유효기간을 나타낸다.
HTTP/1.1 200 OK
Content-Type: application/xhtmll+xml, charset=utf-8
Expires:Thu, 11 May 2010
이 응답에는 2010년 5월 11일 16시까지는 캐시가 유효하다는 것을 서버가 보증하고 있습니다. 클라이언트가 다음번 이 리소스에 접근 할 때는 캐시가 유효기간 내에 있는지에 따라, 서버에 다시 접속할 것인지 캐시를 이용할 것인지를 결정합니다.
리소스를 변경할 가능성이 없는 경우는 캐시의 유효기간을 무한으로 설정하고 싶겠지만, 그런 경우라도 Expires 헤더에는 최장 약 1년 이내로 일시를 넣을 것을 스펙에서는 권장하고 있습니다.
cache-Control - 상세한 캐시 방법을 지정한다
Pragma 헤더와 Expires 헤더는 HTTP 1.0이 정의한 헤더입니다. 간단한 캐시는 이들로 구현할 수 있지만, 복잡한 지정은 할 수 없습니다. 좀 더 복잡한 지정을 가능하게 하기 위해서 HTTP 1.1에서는 Cache-Control 헤더를 추가했습니다. Pragma헤더와 Exires헤더의 기능은 Cache-Control 헤더로 완전히 대용할 수 있습니다.
Pragma : no-cache
Cache-Control:no-cache 와 같습니다.
Cache-Control : max-age:86400
또한, Expires에서는 절대시간으로 유효기간을 표시했는데, Cache-Control에서는 현재로부터의 상대시간으로 유효기간을 설정할 수 있습니다. 위의 예는 86,400초, 즉 현재로부터 24시간 캐시가 유효하다는 것을 의미합니다. Cache-Control헤더에서는 이 밖에도 다양한 식별자와 값이 들어가는데 이들에 의해서 더욱 섬세하게 캐시를 제어할 수 있습니다.
캐시용 헤더의 사용 구분
캐시를 시키지 않을 경우는 Pragma와 Cache-Control의 no-cache를 동시에 지정한다.
캐시의 유효기간이 명확하게 정해져 있는 경우는 Expires를 지정한다.
캐시의 유효기간을 상대적으로 지정하고자 하는 경우는 Cache-Controldml max-age로 상대시간을 지정한다.
조건부 GET
클라이언트가 Expires와 Cache-Control 헤더를 검증한 결과, 로컬 캐시를 그대로 재사용할 수 없다고 판단한 경우라도 조건부 GET를 송신하면 캐시를 재사용할 수 있는 가능성이 있습니다. 조건부 GET은 서버 측에 있는 리소스가 클라이언트 로컬의 캐시로부터 변경되어 있는지 여부를 조사하는 조건을 요청 헤더에 포함시킴으로써, 캐시를 그대로 사용할 수 있는지 검토하는 구조입니다. 조건부 GET은 리소스가 Last-Modified 헤더 또는 ETag 헤더를 가지고 있을 때 이용할 수 있습니다.
If-Modified-Since - 리소스의 갱신일시를 조건으로 한다.
GET/test HTTP/1.1
Host: example.com
If-Modified-Since:Thu, 11 May 2010 16:00:00 GMT
이 요청은 로컬 캐시의 갱신일시가 2010년 5월 11일 16시 정각이라는 것을 나타내고 있습니다. 서버의 리소스가 이 이후로 변경되지 않았다면, 서버는 다음의 응답을 보냅니다.
HTTP/1.1 304 Not Modified
Content-Type: application/xhtmll+xml, charset=utf-8
Last-Modified: Thu, 11 May 2010 16:00:00 GMT
304 Not Modified는 조건부 GET에 대한 응답으로, 서버의 리소스를 변경하지 않았다는 것을 알려주는 스테이터스 코드입니다. 리소스의 갱신일시는 Last-Modified 헤더로 확인할 수 있습니다. 이 응답에는 바디가 포함되지 않기 때문에 그만큼 네트워크 대역을 절약할 수 있습니다.
If-None-Match - 리소스의 ETag(엔티티 태그)를 조건으로 한다.
GET/test HTTP/1.1
Host: example.com
If-None-Match: ab3322028
If-None-Match 헤더는 If-Modified-Since 헤더와 비슷하지만, 지정하는 값이 다릅니다. If-Modified-Since 헤더는 '지정한 시간 이후로 갱신되어 있으면'이라는 조건임에 반해, If-None-Match 헤더는 '지정한 값과 매치하지 않으면'이라는 조건이 됩니다. If-None-Match 헤더에 지정하고 있는 값은 캐시하고 있는 리소스의 ETag 헤더의 값입니다.
위의 조건부 GET의 결과, 서버상의 리소스가 변경되어 있지 않으면 다음의 응답을 반환합니다.
HTTP/1.1 304 Not Modified
Content-Type: application/xhtmll+xml, charset=utf-8
ETag: ab3322028
ETag는 리소스의 갱신 상태를 비교하기 위해서만 사용하는 문자열입니다. 리소스를 갱신했을 때 다른 값이 되는 것이면 어떤 문자라도 상관 없습니다.
ETag의 계산
정적 파일
Apache는 기본적으로 정적 파일의 ETag의 값은 inode번호, 파일 사이즈, 갱신일시를 이용해 자동으로 계산해 줍니다.
단, inode번호는 동일 내용의 파일이라도 파일 시스템이 다르면 다른 값으로 되기 때문에 서버를 분산시킨 경우에는 주의가 필요합니다. 그런 경우는 파일 사이즈와 갱신 일시만으로 ETag의 값을 계산하도록 설계할 수 있습니다.
동적 파일
동적으로 생성한 HTML 페이지와 피드 등의 경우, 정적 파일과는 달리 Apache 등의 웹 서버가 ETag를 자동으로 계산해주지 않습니다. 따라서 ETag를 이용한 조건부 GET을 구현하기 위해선 HTML과 피드를 생성하는 웹 애플리케이션에서 ETag의 값을 계산할 필요가 있습니다.
ETag 값의 계산은 리소스 내용의 해시를 계산하는 방법이 가장 간단하지만, 리소스의 내용을 모두 계산해야하기 때문에 사이즈가 큰 리소스나 데이텁이스에 대해 복잡한 쿼리를 발생시키는 리소스에는 현실적이지 않습니다. 이런 경우는 일반적으로, 리소스의 메타 데이터(갱신 일시, 사이즈 등)를 이용해 생성하거나, 리소스의 갱신 카운터를 준비해서 그것으로 대용하기도 합니다.
Atom : 목적 가운데 하나는 RSS의 스펙이 난립하여 혼란을 초래했기 떄문에 확장성이 있는 피드의 표준 포맷을 책정하려는 것이었습니다. RSS는 주로 블로그의 신착정보를 전달하는 피드의 목적으로 이용되었지만, Atom은 블로그뿐 아니라 검색엔진이나 사진관리 등 다양한 웹 서비스의 웹 API로 이용할 수 있습니다.
멤버 리소스
블로그라면 하나하나의 기사가 멤버 리소스가 됩니다. 이미지 관리 서비스라면 하나하나의 이미지가 멤버 리소스가 됩니다.
멤버 리소스는 XML로 표현할 수 있는 엔트리 리소스와 그 밖의 미디어 리소스로 나눠집니다.
멤버리소스 <-------- 멤버를 복수 포함 컬렉션 리소스(피드로 표현)
엔트리 리소스(엔트리로 표현하는 멤버:text,html,xhtml,그 밖의 텍스트와 XML) , 미디어 리소스(엔트리 이외로 표현하는 멤버:텍스트 이외의 데이터, 멀티미디어 파일)
미디어링크 엔트리(엔트리 리소스 중, 미디어 리소스에 대한 링크를 가진 것 <content>요소의 src속성으로 외부 리소스를 참조한다.
Content-Type: application/atom+xml
Content-Type: application/atom+xml; type=entry
Content-Type: application/atom+xml; type=feed
Content-Type: application/atom+xml; type=feed; charset=utf-8
엔트리의 예
<entry xmlns="http://www.w3.org/2005/Atom">
<id>tag:example.com,2010-08-24:entry:1234</id>
<title>테스트 일기</title>
<updated>2010-08-24T13:11:54Z</updated>
<link href="http://example.com/1234" />
<content>테스트입니다.</content>
</entry>
tag스키마
tag:{DNS명 또는 메일주소},{일자}:{임의의 문자열}
DNS명은 자신이 권리를 가지고 있는 도메인의 호스트명입니다. 메일주소는 자신이 가지고 있는 임의의 메일주소입니다. 여기에 일자정보를 더해, 전 세계에서 고유하다는 것을 보증합니다.
<title><summary>
<author><contributor><name><uri><email>
<updated><published>
<category term="animals" label="동물" scheme="http://example.com/tags" />
<link rel="alternate" hreflang="ja" href="http://example.com/1234" />
<link rel="enclosure" type="audio/mpeg" length="489822" href="http://podcast.example.com/audio/123.mp3" title="Atom에 대한 강연"/>
Atom에서는 엔트리의 내용에 다양한 포맷을 포함할 수 있게 되어있습니다.
텍스트,HTML,XHTML,XML,이미지(바이너리 데이터,Base64 or src)
피드 - 엔트리의 집합
멤버 리소스를 여러 개 가지는 컬렉션 리소스의 표현
엔트리와 공통 메타 데이터 <id><title><author><updated>
피드의 독자적인 메타 데이터 <subtitle>생성프로그램<generator><icon><logo>
Atom의 확장
높은 확장성으로 블로그 이외의 다양한 시스템에서 응용되고 있습니다.
2. Atom Threading Extenstions - 스레드를 표현한다
피드 형식의 데이터는 블로그뿐 아니라 게시판이나 폼, 메일링 리스트 로그 같은 복수 투고자에 의한 콘텐츠에도 적합합니다.
어떤 사람이 투고한 콘텐츠에 다른 사람이 차례차례 답변을 하여 하나의 흐름을 만드는 이른바 스레드 기능입니다.
<thr:in-reply-to>
replies 링크 관계와 thr:count속성 / thr:updated 속성
부모 엔트리 쪽에서 자식 엔트리를 참조할 때 사용하는 것 .
예는 '최초의 블로그 포스팅'의 엔트리를 표현하고 있습니다. 이 엔트리는 replies 링크 관계로 답글에 대한 참조를 가집니다.
3.Atom License Extension - 라이선스 정보를 표현한다.
1. OpenSearch - 검색결과를 표현한다.
Description Document 검색엔진이 제공하는 검색기능을 프로그램이 이해할 수 있는 형식으로 기술하는 XML형식
URL Template Syntax 검색결과 리소스를 표현하는 URL의 검색 쿼리 부분을 파라미터화 하는 스펙
Query Element
Response Element
Atom은 타이틀, 저자, 갱신일시라는 기본적인 메타 데이터를 갖춘 리소스 표현을 위한 포맷입니다. 다양한 애플리케이션용 확장이 준비된 포맷이기도 합니다. 예를 들어 팟 캐스트에 의한 음악전송이나 사진관리, 검색엔진 등입니다.
Atom - 데이터 포맷의 규칙(피드, 엔트리)
AtomPub - Atom이 규정한 피드와 엔트리로 표현하는 리소스의 편집, 소위 말하는 CRUD조작을 실현하기 위한 프로토콜입니다.
REST는 시스템을 설계하기 위한 지침입니다.
AtomPub 의 설계는 REST 스타일에 기초한 프로토콜 스펙입니다.
REST는 아키텍처 스타일이기 때문에, 실제 리소스 설계나 링크 기능의 제공은 시스템 설계자의 손에 달려 있습니다. 여기에는 설계자의 자유도를 확보할 수 있다는 이점이 있는 반면에, REST를 바르게 이해하고 있지 않으면 제대로 설계할 수 없다는 결점도 있습니다.
AtomPub 스펙은 기본적인 리소스 모델과 링크 기능을 제공하므로 우리들이 독자적으로 설계해야 하는 부분이 많이 줄어듭니다.
또한, AtomPub 대응 프레임워크와 라이브러리를 이용하면 구현과정이 단축되고 나아가 표준화된 프로토콜을 이용함으로써 상호운용성도 높아집니다.
멤버 리소스의 조작
엔트리 단위에서의 조작
피드에 포함되어있는 각 엔트리는 고유의 URI를 가집니다.
각각의 URI에 HTTP메서드를 적용하면 CRUD조작을 구현할 수 있습니다.
<link href="http://blog.example.com/entry/1234.atom" rel="edit"/>
이렇게 rel속성이 edit라는 값을 가진 <link>요소를 편집링크라고 부릅니다.
GET 엔트리 취득
PUT 엔트리 갱신 - 취득한 엔트리를 편집하고, 서버에 PUT하여 엔트리 정보를 갱신합니다.
DELETE-엔트리의 삭제
POST-엔트리의 작성
미디어 리소스의 조작
slug 헤더는 AtomPub 가 새로 정의한 헤더입니다. 투고할 미디어 리소스의 URI와 타이틀에 사용할 힌트가 되는 문자열을 %인코딩한 것입니다.
서비스 문서는 컬렉션 리소스의 리스트를 모은 홈페이지와 같은 것으로 생각하면 됩니다.
application/atomsvc+xml이라는 미디어 타입을 이용하고 있습니다.
<service>요소를 루트로 가지는 XML문서입니다.
<service>요소는 자식요소로 반드시 하나 이상의 <workspace>요소를 가집니다. <workspace>는 몇 개의 컬렉션 리소스를 모으기 위한 것입니다.<categories>요소는 컬렉션 리소스에서 이용 가능한 카테고리를 나타냅니다. fixed속성으로 지정된 카테고리 이외의 엔트리를 추가할 것인지 안 할 것인지를 정할 수 있습니다.
AtomPub 의 카테고리는 소셜 북마크의 '태그'에 가깝다고 생각하면 됩니다.
AtomPub 에 적합한 웹 API
-블로그 서비스의 API
-검색 기능을 가진 데이터 베이스의API
-멀티미디어 파일의 repository의API
-태그를 사용한 소셜 서비스의API
AtomPub 에 적합하지 않은 웹 API
-Comet을 이용하는 실시간성이 중요한API
-영상의 스트림 전송 등 HTTP이외의 프로토콜을 필요로 하는API
-데이터의 계층 구조가 중요한 API
-타이틀 작자 갱신일시 같은 Atom 포맷이 제공하는 메타 데이터가 불필요한 API
JSON
JavaScript Object Notation
데이터를 기술하기 위한 언어
JavaScript 기법으로 데이터를 기술할 수 있는 점이 특징입니다.
심플함으로 인해 많은 언어에서 라이브러리를 제공하고 있으므로 프로그래밍 언어 간에 데이터를 주고받을 수 있습니다.
웹 서비스에서는 브라우저가 JavaScript를 실행할 수 있어 호환성이 좋고 XML과 비교하면 데이터 표현이 간결하다는 등이 이점이 있어 Ajax 통신에서 데이터 포맷으로 활용되고 있습니다.
자료형 6가지 (object, array, string, number, boolean, null)
1.오브젝트는 이름과 값의 집합입니다. 이름과 값의 세트를 오브젝트의 '멤버'라고 부릅니다. 자바스크립트에서는 멤버의 이름에 식별자와 수치도 가능하지만, JSON의 멤버의 이름은 항상 문자열입니다. 멤버의 값은 문자열과 수치는 물론 오브젝트나 배열 등 JSON의 자료형이라면 무엇이든 들어갈 수 있습니다.
{
"name":{
"first":"John",
"last":"Doe"
},
"blog":"http://blog.example.com",
"age":34,
"interests": ["Web","XML","REST"]
}
오브젝트는 {}로 감싸줍니다. 멤버는 ,으로 구분하고 멤버의 이름과 값은 :으로 구분합니다.
2.배열은 순서를 가진 값의 집합입니다. 0개 이상의 값을 가질 수 있습니다.
문자열의 배열 ["Web","XML","REST"]
오브젝트의 배열 [{"foo":"bar"},{"key":"value"}]
배열의 배열,빈 배열,복잡한 배열 등등
3.스트링(문자열) JSON의 문자열은 반드시 이중인용부호(")로 감싸줍니다. 에스케이프 표기도 사용할 수 있습니다.
4.number(수치) 수치에는 정수와 부동소수점이 모두 포함됩니다. 수치의 표기는 10진 표기로 한정합니다.
5.boolean(부울린) 참이냐 거짓인가를 취하는 부울린형은 true와 false와 같이 반드시 소문자로 기술해야합니다.
6. null
7. 일시 - 기본적으로 제공하는 자료형에 일시는 없습니다.
8. 링크
JSON에 의한 크로스 도메인 통신
JSONP가 왜 필요하게 되었는지의 배경 - Ajax에서 이용하는 XMLHttpRequest라는 JavaScript의 모듈은 보안상의 제한으로 인해, JavaScript파일을 가져왔던 동일한 서버하고만 통신할 수 있습니다. 자바스크립트가 있는 서버와 다른 서버가 통신할 수 있다면, 브라우저에서 입력한 정보를 사용자가 모르는 사이에 부정한 서버로 전송할 수 있게 되기 때문입니다. 이와 관련해 이렇게 불특정 다수의 도메인에 속하는 서버에 액세스하는 것을 '크로스 도메인 통신'이라고 부릅니다.
복수 도메인의 서버와 통신할 수 없고, 단일 도메인과만 통신해야 한다는 것은 커다란 제약입니다. 예를 들어, 자체 서비스에서는 지도 데이터와 우편번호 데이터를 가지지 않고, 그것들을 제공하고 있는 다른 웹 API로부터 원하는 대로 가져올 수 없기 때문입니다.
콜백 함수를 활용하는 JSONP
XMLHttpRequest에서는 크로스 도메인 통신을 할 수 없지만, HTML의 <script>요소를 이용하면 복수의 사이트에서 자바스크립트 파일을 읽을 수 있습니다. JSONP는 브라우저의 이런 성질을 이용해 크로스 도메인 통신을 구현하는 방법입니다.
itistory-photo-4
