안녕하세요?
프론트엔드 디벨로퍼가 되기로 마음먹었을 때부터 생소한 웹 관련 용어 공부하면서 정리해 보았습니다.
- 1. 웹이란 무엇인가
- 2. 웹의 역사
- 3. REST
- 4. REST라는 아키텍처 스타일
- 5. URI
- 6. HTTP의 기본
- 7. 메소드
- 8. 상태 코드
- 9. HTTP 헤더
- 10. HTML
- 11. JSON
1. 웹이란 무엇인가
1.1. 웹의 용도
- 사람을 위한 것
- 웹 사이트: 야후나 아마존 같은 거
- 각종 디바이스의 설정 화면
: 프린터 같은 네트워크에 연결하는 디바이스의 설정(PC가 리모컨 같은 거보다 효율적)
- 프로그램을 위한 것
- 프로그램용 API: 프로그램으로 해석하고 처리하는 거. 데이터 형식은 JSON이나 XML 같은 거. 여기서는 '웹 API'라고 표현함.
1.2. 웹을 지탱하는 기본적인 3가지 기술
HTTP: 애플리케이션 프로토콜. URI로 조작 대상을 지정하고, 정보를 가져오는 거
URI: 리소스 식별자. HTML의 링크로 사용되고, 정보의 위치를 가리키는 거
HTML: 하이퍼미디어 형식. 정보를 표현하는 거. HTTP로 주고받는 거
1.3. 웹의 특징
- 하이퍼미디어의 하나라는 거: 하이퍼링크로 다양한 미디어를 엮고, 비선형적으로 사용자가 스스로 링크를 선택하는 거
⇔ 반대의 예: 책이나 영화. 앞에서부터 차례로 읽거나 보거나 하는 거 - 분산 시스템이라는 거: 세계 곳곳에 배치된 서버에 세계 곳곳의 브라우저가 접속할 수 있는 거. 프로토콜이 간단한 거가 특징
- 분산 시스템: 여러 컴퓨터를 조합해서 처리를 분산시키는 형식. 엄청난 정보의 조작, 여러 컴퓨터 위의 정보를 일원적으로 다루는 거 등이 가능 ⇔ 집중 시스템: 한 대의 중앙 컴퓨터가 모든 걸 처리
2. 웹의 역사
2.1. 웹 이전
초기의 인터넷에는 웹이 없었다
2.2. 인터넷
- 기원은 1969년, 미국 내의 대학 등의 사이를 회선 연결해 전미를 잇는 네트워크가 존재했다
- 메일은 영숫자만. TCP/IP(실시간 통신)뿐만 아니라 UUCP(버킷 릴레이 방식)도 존재했기 때문에 메일 도착에 지연이 있었다
- 파일 교환을 위한 FTP, UNIX 호스트에 원격 접속하기 위한 telnet 등도 탄생했다
2.3. 하이퍼미디어
- 1945년의 미국 연구자가 제안했던 것(정보 검색 시스템에 관한 논문. 책이나 파일을 상호 링크로 따라갈 수 있음)
- 1965년에 Nelson이 하이퍼미디어를 고안(Xanadu). 하지만 개발은 실패로 끝남
- 1987년, Apple에서 HyperCard가 개발됐다. 네트워크로 데이터를 주고받는 기능은 없었다
- 당시 웹은 링크가 끊어질 가능성이 있다는 등 불완전하다고 생각되었지만, 필요 최소한의 링크 기능만을 갖추고 있었기 때문에 현재 보급되고 있다. 위의 것들은 복잡한 것이 문제점이었다고 할 수 있다
2.4. 분산 시스템
- 통신 상대가 어느 정도 한정되어 있는 인트라넷 환경까지만 작동했다
2.5. 웹의 탄생
- 1990년, 하이퍼미디어를 이용한 인터넷 기반의 분산 정보 관리 시스템으로 제안됐다
- 1993년, IE나 Firefox의 원류가 되는 브라우저 Mosaic가 공개되고, 웹의 보급이 진행됐다
- 웹과 웹 이전의 시스템의 차이는, '인터넷을 이용한' 하이퍼미디어로 설계된 것이다
- 인터넷을 이용함으로써, 불특정 다수의 정보를 링크로 서로 연결할 수 있게 됐다
- HTTP를 이용해 클라이언트와 서버 사이의 인터페이스를 고정함으로써, 불특정 다수의 클라이언트에게 서비스를 제공할 수 있게 됐다
2.6. 웹의 표준화
- 여러 기업이 웹에 참여하게 되면서 HTTP, URI, HTML 등의 표준화가 요구되고, 1994년에 단체가 설립됐다
- '브라우저 호환'이라는 말은 이 시대부터 존재했다
- HTTP의 사양 작성에 참여했던 인물이, 웹의 성공 요인의 분석을 하고, 그 결과 하나의 아키텍처 스타일로서 'REST'를 제안했다
- HTTP는 '리소스의 상태'의 '표현'을 운반하기 위한 프로토콜이라는 개념
2.7. 웹 API를 둘러싼 논쟁 'SOAP VS REST'
- 1990년대 후반부터 웹의 용도의 다양화에 따라, 프로그램으로 웹을 조작하고 싶은 요구가 나오기 시작했다
- 2004년부터 시작된 웹2.0의 흐름 속에서 Google이나 Amazon이 REST 형식의 웹 API를 제공하기 시작했다
- SOAP는 메시지 전송의 방법만을 정한 사양이기 때문에, 표준화가 어려웠다
- Amazon이 2002년에 SOAP 형식과 REST 형식(정해진 URI를 HTTP로 GET하는 방식. 기술적으로는 정확하지 않지만 이렇게 불렸다)을 이용해 AWS를 개발
- 웹2.0에서는 매쉬업이 중요. 여러 웹 API가 제공하는 정보를 조합해 하나의 앱을 실현하는 방법. REST에서는 간단하게 HTTP나 URI로 리소스를 조작할 수 있었기 때문에 받아들여졌다
2.8. 그리고 현재
- Ajax 등의 기술적 브레이크스루도 있어, 웹에서 UI가 통일되게 되었다
- 항상 최신의 정보를 웹을 통해 제공할 수 있다
2.9. 부연설명: 하이퍼미디어 포맷의 역사
- 초기의 웹에서는 HTML이 유일한 하이퍼미디어 포맷(정보의 표현 방식)이었다
- microformats: HTML의 구조는 그대로 두고 HTML에 다양한 의미를 부여할 수 있는 기술
- RSS: 웹의 최신 정보를 서버에서 배포하고 체크하는 기술. 최종적으로 Atom에 표준화됐다
- JSON: 데이터를 기술하기 위한 포맷.(HTML이나 Atom은 XML 기반의 것이기 때문에, 표기가 장황해져 데이터 표기에는 적합하지 않다)
3. REST
4. REST라는 아키텍처 스타일
- REST는 웹의 아키텍처 스타일
- 클라이언트/서버에서 파생된 것(몇 가지 제약을 더한 것)이므로, 네트워크 시스템의 아키텍처 스타일이라고 할 수 있어
- 아키텍처 스타일이란, 시스템의 아키텍처를 결정할 때의 나침반
4.1. REST에서 중요한 '리소스'라는 개념
- 리소스란 웹상에 존재하는, 이름을 가진 모든 정보
- 예: 도쿄의 날씨 예보, 도쿄역의 사진, 이 블로그
- 리소스는 URI로 식별할 수 있고, 그러면 프로그램은 정보에 접근할 수 있어
- URI가 나오기 전에는, 디렉토리명이나 파일명, 로그인 정보를 전달해야 했어
- 한 리소스에 여러 URI를 붙일 수도 있어
4.2. REST를 구성하는 특징
- 클라이언트/서버(여기에 아래 5가지 제약을 추가한 것이 REST)
: UI(클라이언트)와 서버처리를 분리하면, 멀티플랫폼(PC나 스마트폰, 게임기...)이 가능해지는 등의 장점이 있어 - 스테이트리스 서버
: 서버 쪽에서 애플리케이션의 상태를 갖지 않으면, 서버의 구현을 간단하게 할 수 있어
※예외로서 HTTP를 스테이트풀하게 하는 요소: 쿠키를 사용한 세션 관리 - 캐시
: 한 번 가져온 리소스를 클라이언트 쪽에서 재사용하면, 서버와의 통신을 줄이고 처리를 효율화할 수 있어 - 통일 인터페이스
: 인터페이스를 고정. 예를 들어 GET이나 POST 등 8개의 메소드밖에 정의하지 않음으로써, 구현의 독립성이 향상돼 - 계층화 시스템
: 로드밸런서나 프록시를 CL/SV 사이에 설치할 수 있지만, CL 쪽은 그것을 의식하지 않고 SV를 이용할 수 있어(통일 인터페이스를 채택함으로써 계층화가 가능해지는 거야) - 코드온디맨드
: 프로그램을 클라이언트에 다운로드해서 실행하는 거야 예) 자바스크립트
5. URI
5.1. URI의 포인트
- 리소스의 이름이다
- 수명이 길다
- 브라우저의 주소창에 표시한다
5.2. URL과의 차이(URI와 URL과 URN)
- URL과 URN을 총칭한 것이 ‘URI’
- URN은 다음과 같은 표기. 리소스에 영구적인 ID를 부여하고, 그것을 이용해 접근한다
- urn:isbn:12345678901234567890
- URL을 이용할 경우, 서버 장애, 도메인 변경 등으로 사용할 수 없게 될 가능성이 있다
- 최근에는 URL을 영구적으로 사용할 수 있도록 해야 한다는 생각이 퍼지고 있어서, 거의 URL이 사용되고 있다
5.3. 구성
- HTTP의 기본: TCP/IP의 기초 지식, HTTP의 메시지 구조, 스테이트리스성
- HTTP 메소드: 각 메소드의 특징, 멱등성
- 스테이터스 코드: 코드의 분류와 의미, 에러 처리
- HTTP 헤더: 헤더의 역사, 구성 내용, 인증 방식 등
6. HTTP의 기본
6.1. HTTP란
- Web 상에서 클라이언트/서버 간에 리소스를 주고받기 위한 프로토콜
- REST의 특징인 통일 인터페이스, 스테이트리스 서버, 캐시 등을 구현하고, Web의 기반을 이루고 있다
6.2. TCP/IP란
- HTTP는 TCP/IP를 기반으로 하고 있다
6.3. IP
- OSI 참조 모델에서 인터넷 계층에 해당하며, 네트워크에서 데이터를 실제로 주고받는다
- 데이터를 주고받을 때는 지정한 IP 주소를 수신처로 하여, 패킷 단위로 보낸다
- 자신의 네트워크에서 보내는 것만을 보장하고, 수신처까지 도착하는지는 보장하지 않는다
6.4. TCP
- OSI 참조 모델에서 전송 계층에 해당하며, 데이터의 송신을 보장한다
- 연결할 상대에게 커넥션을 맺고, 커넥션을 사용하여 데이터의 누락을 체크한다
- HTTP에서는 80번 포트를 기본으로 사용한다
6.5. HTTP의 버전
필자가 배운 책이 나온 시점에서 가장 널리 사용되고 있는 버전은 HTTP1.1
※ 이미 HTTP2나 3이 나온 시대이므로, 자세한 내용은 생략합니다
6.6. HTTP의 구조 ①클라이언트와 서버
- 클라이언트...Web 브라우저
- 서버...Web 서버. 정보를 제공
- 클라이언트가 서버에 연결할 때에 요청을 내고 서버로부터 응답을 받는다(요청/응답형)
6.7. HTTP의 구조 ②요청과 응답
- 요청 후, 클라이언트는 응답이 돌아올 때까지 대기한다(동기형)
- URL을 두드려서 Web 사이트에 접속했을 때의 처리의 흐름을 아래에 기술
6.7.1. 클라이언트 측
- DNS를 사용하여 URL에서 호스트명을 이름 해결하고, 얻은 IP 주소의 TCP 80번 포트에 연결하고, 요청을 송신한다
- 응답 메시지를 수신
- 분석하고, 또 요청 발행이 필요하면 반복한다(이미지나 스타일시트에 대한 링크가 포함되어 있는 경우 등)
- 돌아온 HTML을 렌더링하여 윈도우에 표시한다
6.7.2. 서버 측
- 요청 메시지를 수신하면 분석
- 해당 페이지의 HTML을 렌더링하는 애플리케이션에 처리를 위임하고, 결과의 HTML을 얻는다
- 헤더를 첨가하여 응답 메시지를 구성
- 응답 메시지를 클라이언트에 반환한다
6.8. HTTP의 구조 ③HTTP 메시지
6.8.1. 요청 메시지
1행은 '요청 라인'
- 메소드(GET 등)
- 요청 URI(/test?debug=true
~) - 버전(HTTP/1.1)
2행 이후는 '헤더'(메시지의 메타데이터)
※여러 개의 헤더를 가질 수 있다
※생략 가능
- '이름:값'과 같은 형식
- Host 헤더(필수) (Host: example.kr:8080) ←포트 번호를 지정
- 바디가 이어질 수도 있다(갱신할 리소스 등) ※생략 가능
6.8.2. 응답 메시지
1행은 '상태 라인'
- 버전(HTTP/1.1)
- 상태 코드(200 등) ←요청 성공 시
- 텍스트 프레이즈(OK 등)
2행 이후는 '헤더' ※생략 가능
- 바디가 이어질 수도 있다(HTML 등) ※생략 가능
- 헤더와 바디는 공백 행으로 구분된다
6.8.3. HTTP의 구조 ④스테이트리스성
- HTTP는 스테이트리스의 구조를 채택하고 있다
6.9. 스테이트풀
- 간결
- 서버가 그동안의 클라이언트의 요청을 기억하고 있다(우리 인간의 대화도 스테이트풀)
6.10. 스테이트리스
- 중복
- 클라이언트는 매번 그동안의 요청도 포함하여, 반복하여 요청한다
7. 메소드
7.1. 8가지의 메소드
- GET
- POST
- PUT
- DELETE
- HEAD
- OPTIONS
- TRACE: 거의 사용되지 않음
- CONNECT: 거의 사용되지 않음
7.2. 대표적인 메소드
- GET(읽기)
- POST(생성)
- PUT(생성·업데이트) ※POST로 대용 가능
- DELETE(삭제) ※POST로 대용 가능
7.3. POST와 PUT의 구분(생성 처리)
- 위에서 말했듯이, POST로도 PUT으로도 생성 처리가 가능함
7.3.1. POST
- 리소스의 URI는 서버 측이 정함
- 예: 트위터
7.3.2. PUT
- 리소스의 URI를 지정할 수 있음
- 예: 위키백과
- URI의 문자수 제한 등 고려가 필요하기 때문에, 특별한 이유가 없으면 POST를 사용하는 것이 바람직함
7.4. PUT/DELETE의 POST에 의한 대용
7.4.1. 왜 대용을 생각하는가
- 브라우저에 따라서는 GET과 POST만 대응하는 경우가 있음
- 보안상의 이유로 프록시 서버가 GET과 POST 이외의 접근을 제한하는 것도 있음
7.4.2. 대용 방법
- _method 파라미터(Ruby on Rails)
- X-HTTP-Method-Override(Google의 GData)
7.4.3. 조건부 요청
- 메소드를 실행할지 말지의 조건을 붙여, 실행 유무를 서버가 선택할 수 있도록 하는 것이 가능함
- 예: 헤더에 리소스의 갱신 일시를 첨부하고, 이 일시 이후 갱신되었으면 GET 처리를 함
7.5. 멱등성(Idempotence)과 안전성
7.5.1. 멱등성
- 어떤 작업을 몇 번 하더라도 결과가 같아지는 것
- PUT이나 DELETE는 멱등. 같은 PUT(DELETE)를 몇 번 하더라도 같은 결과
멱등성(Idempotence)은 어떤 작업이 몇 번을 반복하더라도 결과가 동일하게 되는 특성을 나타냅니다
7.5.2. 안전성
- 작업 대상의 리소스의 상태를 변화시키지 않는 것
- GET과 HEAD는 안전
7.5.3. POST
- POST는 안전도 멱등도 아님
- 요청의 결과, 리소스가 변화할 가능성도 있고 전회와 결과가 달라질 가능성도 있음
- ※PUT이 멱등이 아니게 되는 패턴 등, 예외도 책 안에서 소개되고 있음
7.6. 요약
다음의 점에서 HTTP는 뛰어난 프로토콜이라고 할 수 있음
- HTTP는 제한된 메소드로 구성됨=REST의 통일 인터페이스 제약
- GET의 안전성
- PUT과 DELETE의 멱등성
- 만약에 되면 뭐든지 할 수 있는 POST
8. 상태 코드
8.1. 분류와 자주 쓰이는 코드
앞자리의 숫자로 경우를 나누는 것으로 CL/SV 간의 약속을 줄이고, 결합을 느슨하게 하는 효과(느슨한 결합)
8.1.1. 1xx: 처리 중
8.1.2. 2xx: 성공
- 200: 요청 성공
- 201: 리소스 생성 성공
8.1.3. 3xx: 리다이렉트
- 301 리소스의 영구적인 이동
- 303 다른 URI의 참조
8.1.4. 4xx: 클라이언트 에러
- 400 Bad Request 요청의 잘못
- 401 Unauthorized 접근권의 불법
- 404 Not Found 리소스의 부재
8.1.5. 5xx: 서버 에러
- 503 Service Unavailable 서비스 정지
9. HTTP 헤더
9.1. HTTP 헤더의 의미
- 헤더에는 메시지의 메타데이터가 설정되어 있다
- 클라이언트나 서버는 헤더를 보고 메시지에 대한 행동을 결정한다
인증이나 캐시의 기능은, 헤더를 메소드나 상태 코드와 조합하여 구현되어 있다
9.2. HTTP 헤더의 역사
9.2.1. 메일과 공통으로 있는 헤더가 있다
- Content-Type, Date 등
- HTTP 헤더의 사양은 전자 메일의 메시지 사양을 바탕으로 정의되었기 때문
- 메일과 HTTP에서 다른 점은, HTTP는 양방향 통신, 메일은 단일 방향의 통신이라는 것
- 그래서, HTTP에서는 전자 메일에는 없는 헤더도 존재한다
9.2.2. 날짜 헤더
- 예: Date, Expires
- GMT 형식으로 표현
- 예) Date:Tue, 06 Jul 2010 03:21:05 GMT
9.2.3. MIME 미디어 타입
- 리소스의 표현의 종류를 지정
9.2.4. Content-Type
- 예) Content-Type:application/xhtml+xml; charset=utf-8
- 'application/xhtml+xml'이 미디어 타입
- 타입: application(이미지, 음성, 영상, 텍스트 이외)
- 서브 타입: xhtml+xml(XML이라는 것을 나타냄)
- charset 파라미터는, XHTML 문서를 UTF-8로 인코딩하고 있다는 것을 나타냄
9.2.5. 언어 지정 헤더
- Content-Language의 값은 '언어 태그'라고 부른다
- 예)Content-Language; ko-KR
9.3. 콘텐츠 네고시에이션
9.3.1. 클라이언트와 서버가 협상하여 미디어 타입이나 문자 인코딩, 언어 태그를 정할 수도 있다
- Accept 헤더
- Accept-Charset 헤더
- Accept-Language 헤더
9.3.2. Content-Length
- 메시지에 바디가 있는 경우, 그 크기를 10진수의 바이트로 나타낸다
- 예)Content-Length:5538
9.3.3. 청크 전송
- 동적으로 이미지를 생성하는 같은 웹 서비스의 경우, 파일 크기가 정해지기 전부터 응답을 조금씩 전송할 수 있다
- 예) Transfer-Encoding: chunked
9.4. 인증
9.4.1. Basic 인증
- 사용자 이름과 비밀번호에 의한 인증 방식
- 사용자 이름과 비밀번호를 ':'로 연결하고 Base64로 인코딩(※)한 문자열을 Authorization 헤더에 설정
- ※데이터를 64가지의 문자열로 표현하는 인코딩 방식
- HTTPS로 통신로 상에서의 암호화를 권장
9.4.2. Digest 인증
- 메시지에 해시 함수를 적용한 결과의 해시 값을 사용한다
- 인증 정보 없이 먼저 요청을 전송하고, 돌아온 챌린지를 사용하여 다음 요청을 구성한다
- 인증에 필요한 정보가 얻어졌다면, 사용자 이름과 비밀번호를 사용하여 다이제스트를 생성한다
- 클라이언트 측의 작업이 번거로운 때문에 별로 보급되어 있지 않다
9.4.3. WSSE 인증
- HTTP1.1에서는 표준 외. AtomPub 등의 WebAPI의 인증에 사용된다
- 비밀번호 그 자체를 NW 상에 흘릴 필요가 없고, Digest 인증만큼 수고가 들지 않는다
- 하지만 서버 측에서는 생의 비밀번호를 저장해 두어야 한다
9.4.4. 부가설명: OAuth
- 웹 서비스 간에 데이터를 주고받을 수 있게 하는 위한 사양(인가의 위임)
9.4.5. 캐시
- 서버에서 가져온 리소스를 클라이언트의 로컬에 축적하고 재사용
9.4.6. 헤더에 가지는 정보
- 캐시 가능 여부(Pragma)
- 유효 기간(Expires)
- 상세한 캐시 방법(Cache-Control): 위의 2점의 헤더의 기능을 대용 가능
9.4.7. ETag
- 캐시된 리소스에는 엔티티 태그(ETag 헤더)의 정보를 가진다
- 리소스의 갱신 상태를 비교하기 위해 사용한다(갱신하면 값이 바뀐다)
####지속적 연결
- HTTP1.0에서는 클라이언트가 확립한 TCP 커넥션을 응답 반환의 때마다 끊었다
- HTTP1.1에서는 연결을 계속하는 사양이 되었다
- 응답을 기다리지 않고 같은 서버에 요청을 전송할 수 있다(파이프라인화) 때문에, 더 효율적으로 메시지를 처리할 수 있다
- 끊을 경우는, 요청의 Connection 헤더에 close라는 값을 지정한다
9.5. 구성
9.5.1. HTML
- 제목이나 단락 등의 구조를 정의한 문서 형식
9.5.2. microformats
- HTML에 비해, WebAPI를 프로그램용으로 별도로 준비할 필요가 없고, 유지보수성 등의 면에서 우수하다
9.5.3. Atom
- 블로그뿐만 아니라 검색 엔진 등 다양한 웹 서비스의 WebAPI로서 활용 가능
9.5.4. Atom Publishing Protocol(AtomPub)
- Atom은 데이터 형식의 규정인 반면, AtomPub은 Atom을 활용한 리소스 편집(CRUD작업) 프로토콜
- 블로그나 검색 데이터베이스에는 적합하지만, 실시간성이 중요한 API, 데이터의 계층 구조가 중요한 API 등에는 적합하지 않다
9.5.5. JSON
- 위의 XML계의 리소스 표현과 달리, 데이터를 표현하는 형식
※사정상, 현재 시점에서는 'HTML', 'JSON'만 정리하게 되었습니다
10. HTML
10.1. HTML의 미디어 타입
- 2가지 존재한다
10.1.1. text-html
- SGML기반의 HTML
10.1.2. application/xhtml*xml
- XML기반의 XHTML
10.1.3. XML의 사양
- 나무 구조로 되어 있고, 요소(head 등)를 중첩하여 표현한다
- 처음에 XML이라는 것을 선언한다
10.1.4. HTML의 구성
- 헤더와 바디로 구성된다
10.1.5. 헤더
- 문서의 메타데이터
10.1.6. 바디
문서의 내용 그 자체
블록 레벨 요소: 단락이나 제목 등 큰 덩어리
인라인 요소: 블록 레벨 요소 안에 들어가는, 강조나 개행, 이미지 삽입 등
10.2. 링크
10.2.1. 요소(앵커)
- 블록 요소 안에서 다른 웹 페이지에 링크하기 위한 태그
- HTML의 헤더에서 웹 페이지의 관계를 지정한다
10.2.2. 요소
- 이미지 삽입, 기타 요소(동영상 등)의 삽입
폼
- 링크 대상의 URI에 GET과 POST가 발행할 수 있다
- 요소에서는 GET밖에 발행할 수 없지만, POST도 발행할 수 있다(리소스의 생성 등)
10.2.3. rel속성
- 요소가 가질 수 있다
- 링크 원과 링크 대상의 리소스의 관계를 기술한다
- stylesheet이 대표 예
11. JSON
11.1. JSON이란
- 데이터를 표현하는 형식
- JavaScript표기법. 많은 프로그래밍 언어가 라이브러리를 준비하고 있어, 언어 간에 데이터를 주고받는 것이 용이하다
11.1.1. 미디어 타입
- application/json
- UTF-8,16,32 중 하나로 인코딩하는 규칙
- UTF-8로 인코딩한 JSON의 경우
- Content-Type: application/json; charset=utf-8
11.1.2. 사용 가능한 데이터 타입
- 객체: 이름과 값의 집합(멤버라고 부른다). 멤버의 이름은 항상 문자열. 값은 아래 어느 것도 사용할 수 있다
- 배열
- 문자열
- 숫자
- 부울
- null
{
"name": Jack",
"age":34,
"interests":["web","xml","rest"].
"address":{"pref": "la" , "region":"westside"}
}
11.2. JSONP에 의한 크로스 도메인 통신
- JSON with Padding의 약자
11.2.1. 크로스 도메인 통신이란
- 불특정 다수의 도메인에 속하는 서버에 접근하는 것
- Ajax에서는 JavaScript가 있는 서버와 다른 서버와는 통신할 수 없다
- 실제로는 서비스 구성 상, 다른 서버의 WebAPI와 통신이 필요한 상황도 있다(지도 데이터 등)
11.2.2. script요소에 의한 해결 방법
- script요소는 브라우저의 보안 제한을 받지 않는다
- JSONP에서는 JSON을 함수명으로 래핑하고, 도메인이 다른 서버에서 데이터를 가져온다
끝.
'Javascript' 카테고리의 다른 글
미래의 React는 아마도 SvelteJS처럼 컴파일될겁니다 (1) | 2024.02.24 |
---|---|
유용한 자바스크립트 코드 모음집 (0) | 2024.02.17 |
JavaScript의 Promise, 그것이 알고싶다 (0) | 2024.02.13 |
TypeScript에서 webpack과 Babel의 필요성을 역사적 관점에서 본다 (1) | 2024.02.13 |
자바스크립트 named export와 default export 차이점 이해하기 (1) | 2024.02.13 |