웹을 지탱하는 기술 정리

• 웹이 왜 이런 스펙을 가지게 되었는지 (HTTP, URI, HTML)
• 이 스펙을 가지고 웹 서비스를 설계하는 방법

API: 프로그램을 위한 인터페이스이기 때문에 프로그램에서 다루기 쉬운 데이터 포맷 사용 Ex. XML, JSON

API 로서의 웹: 웹 서비스

URI: HTML로 표현되는 온갖 정보를 가리킴

URI ↔ HTTP ↔ HTML — 심플함

웹

• 하이퍼미디어
  • Memex → Xanadu → HyperCard
  • 문제점
    • 단방향 링크
    • 링크 단절 위험
    • 버전 관리 못함
    • 트랜스클루젼 지원 안 함
• 분산시스템
  • 중앙 집중 → RCP(분산 시스템 실현 위한 기술) → CORBA, DCOM(RPC에서 객체중심으로)
  • 문제점
    • 성능
    • 프로그래밍 언어 혼재, 데이터 형 변환
    • 버전업 호환성
    • 부하 분산

이를 웹으로 해결

팀 버너스 리의 웹(서버/브라우저 구현) → Mosaic(이미지) → HTTP, URI, HTML 표준화 요구

RFC 표준, 이후 W3C에서 표준화 (HTML, XML, HTTP, URI, CSS 등)

브라우저 전쟁

REST

• 로이 필딩
  • 웹이 왜 이렇게 성공했는지를 SW 아키텍처 관점에서 분석한 논문
• 웹 아키텍처 스타일
• Resource state representation을 transfer 한다.

HTML 만으로 다양한 요구 충족 못함 → microformats (HTML에 다양한 의미를 더한 것)

RESS 개발 → Atom에서 표준화

HTML, Atom: XML 베이스 → 표기 중복 많음 → 단순환 포맷 JSON이 de facto standard가 됨

프로그램으로 조작 가능한 웹 API 논의 시작

• SOAP, WS-*
  • RPC/분산 오브젝트 그룹
  • HTTP를 트랜스포트 계층의 프로토콜로 다룸
  • 표준화 경쟁 → 사양 많아짐 → 구현 어려워짐
• SOAP VS. REST
  • 구글, 아마존이 REST 형식 채용한 웹 API 제공 시작(2004, 웹 2.0)
  • 중요한 요소: Mashup. 여러 웹 API로 하나의 application 개발하는 것

아키텍처 스타일

• 종류
  • REST, Pipe and filter, event system

REST

• 순수한 서버/클라이언트 아키텍처 스타일에 여러 제약이 더해진 것

리소스

• 이름을 가진 웹 상의 모든 정보. 식별하기 위해 이름 사용
• 이름을 가진 리소스가 URI
  • 어드레스 가능성(Addressibility, 접근할 수 있는 상태인지)
  • 하나의 리소스가 여러 URI 가질 수 있음
• 서버와 클라이언트가 주고 받는 리소스, 데이터는 리소스 표현이라고 함. Ex. PDF, img

REST 아키텍처 스타일의 구성 요소

• 서버/클라이언트 구조
  • 장점: 멀티 플랫폼 클라이언트 지원, 유저 인터페이스를 클라이언트에서 담당, 서버 확장 용이
• Stateless 서버
  • 클라이언트 어플리케이션 상태를 서버에서 관리하지 않아 서버 구현이 간략해짐
  • 하지만, 현실에서는 stateful한 웹 서비스가 많음 - 쿠키를 통한 세션 관리를 이용함
• 캐시
  • 한 번 가져온 리소스를 클라이언트에서 다시 이용하기 위해 사용
  • 통신량이 줄어드는 장점이 있지만, 오래된 캐시 사용 시 정보의 신뢰성이 떨어짐
• 유니폼 인터페이스
  • URI로 지정한 리소스에 대한 조작을 통일된 인터페이스로 수행
  • 모든 서버가 같은 인터페이스를 채용
• 계층화 시스템
  • 유니폼 인터페이스의 부가적 이점
    • 서버/클라이언트 사이에 로드 밸런서, 액세스 제어를 위한 프록시 추가해도 클라이언트는 동일한 인터페이스로 접근 가능
• 코드 온 디맨드
  • 코드를 서버에서 다운받아 클라이언트에서 실행 Ex. JS, Flash, Java 애플릿
  • 장점은 클라이언트 확장이 용이함(기능 추가)
  • 단점은 프로토콜의 가시성이 떨어짐(통신의 의미와 접근하는 리소스가 무엇인지 불명확해짐)

REST가 아니라면 P2P등도 있다. 서버 없이 피어끼리 통신

URI

• 유니폼 리소스 식별자
• http://example.com/something은 스킴(프로토콜, 아닌 경우 존재)과 호스트명(도메인 명 혹은 주소), path(호스트 내 하나의 리소스)로 구분
• 문장으로 인식; 해당 리소스에 http로 접근한다
• 유닉스의 파일 시스템 구조를 따른다: ‘/’는 루트를 의미하고, /로 디렉터리를 구분

HTTP 역사

• HTTP 0.9 - 탄생
  • 버너스 리가 90년에 개발
  • 헤더 없었고, 메서드는 GET 뿐
• HTTP 1.0 - 최초 표준화
  • 헤더 도입, 다른 메서드들 추가
• HTTP 1.1 - 완성(97년)
  • 채널 전송, Accept 헤더에 의한 컨텐트 네고시에이션, 복잡한 캐시 조작, 지속 연결 지원

HTTP는 동기형 프로토콜; 서버에서 처리가 오래 걸려도 클라리언트는 계속 대기

PUT과 POST의 차이

결론은 POST 쓰기

멱등성과 안전성

멱등성: 어떠한 조작을 여러 번 반복해도 결과가 같음 Ex. 1로 바꾸는 작업을 100번 해도 결과는 1

안전성: 조작을 가해도 리소스의 상태가 변화하지 않음

• 멱등하고, 안전: GET, HEAD
• 멱등하지만 안전하지 않음: PUT/DELETE
• 안전하지만 멱등하지 않음: POST

→ 메서드의 오용 여부는 각 메서드가 그에 맞는 멱등성과 안전성을 지키고 있는지로 귀결됨.

HTTP 헤더

• 날짜, 시간
• MIME 미디어 타입
• charset
• 언어 태그
• 컨텐트 네고시에이션
• Content-Length와 청크 전송
• 인증
• 캐시