Study

3장 명령어 03-1 소스 코드와 명령어 고급 언어와 저급 언어 고급 언어(high-level programming language): 사람을 위한 언어 Python, C, Java, … 저급 언어(low-level programming language): 컴퓨터가 직접 이해하고 실행할 수 있는 언어 기계어(machine code): 0과 1의 명령어 비트로 이루어진 언어 어셈블리어(assembly lanaguage): 기계어를 읽기 편한 형태로 번역한 언어 고급 언어로 작성된 소스 코드가 실행되려면 저급 언어(명령어)로 변환되어야 함 컴파일 언어와 인터프리터 언어 컴파일 언어 컴파일러에 의해 소스 코드 전체가 저급 언어로 변환되어 실행되는 고급 언어 ex) C 컴파일(compile): 컴파일 언어로 작성된 소스 코드의 전체가 저급 언어로 변환되는 과정 컴파일러(compiler): 컴파일을 수행해 주는 도구 컴파일러가 소스 코드 내에서 오류를 하나라도 발견하면 컴파일에 실패 목적 코드(object code): 컴파일러를 통해 저급 언어로 변환된 코드 목적 파일: 목적 코드로 이루어진 파일 컴파일러는 소스코드를 컴파일하여 목적 코드를 생성한다. 목적 코드는 컴퓨터가 이해하고 실행할 수 있는 저급 언어라 빠름 인터프리티 언어 인터프리터에 의해 소스 코드가 한 줄씩 실행되는 고급 언어 ex) Python 한 줄씩 저급 언어로 변환하여 실행 인터프리터(interpreter): 한 줄씩 실행하는 도구 소스 코드 전체를 저급 언어로 변환하는 시간을 기다릴 필요가 없음 한 줄씩 실행되어 오류가 발견되기 전까지는 올바르게 수행 한 줄씩 저급언어로 해석하며 실행하여 느림 둘은 명확히 분리된 개념이 아니라 둘 모두에 속하는 언어도 존재함 링킹(linking) 컴파일된 목적파일에서 사용하는 기능을 연결 목적 코드 ≠ 실행 파일 어떤 목적파일에서 실행하는 기능이 다른 목적파일에 있다면 두 목적 파일을 연결해야 한다. 03-2 명령어의 구조 연산 코드와 오퍼랜드 명령어 = 연산 코드 + 오퍼랜드 연산 코드(operation code, 연산자): 명령어가 수행할 연산 연산 코드 필드: 연산 코드가 담기는 영역 오퍼랜드(operand, 피연산자): 연산에 사용할 데이터 또는 데이터가 저장된 주소 오퍼랜드 필드(주소 필드): 오퍼랜드가 담기는 필드 오퍼랜드 N-주소 명령어: 오퍼랜드 N개 (0개 이상) 연산 코드 데이터 전송, 산술/논리 연산, 제어 흐름 변경, 입출력 제어 등 주소 지정 방식 오퍼랜드에 데이터를 담을 경우: 오퍼랜드에 할당된 크기 만큼만 데이터를 처리 가능 ex) n비트 명령어에 m비트가 연산 코드 필드라면, 오퍼랜드에 담는 데이터의 가짓수는 2^(n-m) 뿐 주소를 담으면 주소의 크기만큼 처리 가능한 데이터의 가짓수가 증가 ex) 오퍼랜드에 한 주소에 16비트를 저장하는 메모리의 주소를 담으면 데이터 가짓수는 2^16 유효 주소(effective address): 연산의 대상이 되는 데이터가 저장된 위치 주소 지정 방식(addressing mode): 연산에 사용할 데이터 위치를 찾는 방법 즉, 유효 주소 찾는 방법 CPU 외부에 있는 메모리에 접근하는 것보다 CPU 내부에 있는 레지스터에 접근하는 것이 더 빠름 즉시 주소 지정 방식 immediate addressing mode 연산에 사용할 데이터를 오퍼랜드 필드에 직접 명시 빠르지만, 표현할 수 있는 데이터의 크기가 작음 직접 주소 지정 방식 direct addressing mode 오퍼랜드 필드에 유효 주소를 직접 명시 오퍼랜드 필드의 길이만큼 표현할 수 있는 주소의 크기가 작아짐 간접 주소 지정 방식 indirect addressing mode 오퍼랜드 필드에 유효 주소의 주소를 명시 표현할 수 있는 유효 주소의 범위는 넓어짐 메모리 접근이 2번 필요하여 느림 레지스터 주소 지정 방식 register addresing mode 연산에 사용할 데이터를 저장한 레지스터를 오퍼랜드 필드에 직접 명시 직접 주소 지정 방식보다 빠름(레지스터 읽기의 속도 > 메모리 읽기의 속도) 레지스터 간접 주소 지정 방식 register indirect addressing mode 연산에 사용할 데이터를 메모리에 저장 그 유효 주소를 저장한 레지스터를 오퍼랜드 필드에 저장 레지스터 접근 + 메모리 1회 접근이라 간접 주소 지정 방식보다 빠름 스택과 큐 스택 스택(stack): LIFO(Last In First Out) 자료구조 PUSH(데이터 저장), POP(데이터 추출) 큐 큐(queue): FIFO(First In First Out) 자료구조

2장 데이터 2-1. 0과 1로 숫자를 표현하는 방법 정보 단위 비트(bit): 0과 1을 나타내는 가장 작은 정보 단위 8비트 → 1바이트(byte) 1000 바이트 → 1KB(kilobyte) 1024 바이트 → 1KiB byte -(x1000)→ KB -(x1000)→ MB -(x1000)→ GB → … byte -(x1024)→ KiB -(x1024) → MiB -(x1000) → GiB → … 1워드(word) → CPU가 한 번에 처리할 수 있는 데이터 크기 이진법 이진수 8표기 → 0b 1000 (0b로 이진법인지 십진법인지구분) 16진수 → 0x 붙여 표기 ...

1장 컴퓨터구조의 이해 컴퓨터가 이해하는 정보 명령어 데이터 컴퓨터의 핵심 부품 중앙처리장치(Central Processing Unit) 산술논리연산장치(Arithmetic Logic Unit) ⇒ 계산 제어장치(Control Unit) ⇒ 제어 신호(control signal)을 보내고 명령어 해석 레지스터(register) ⇒ CPU 내부의 작은 임시 저장 장치 주기억장치(main memory) 보조기억장치(secondary storage) 입출력장치(Input/Output device) 메모리 프로그램이 실행되려면 반드시 메모리에 저장되어 있어야 한다. 메모리는 현재 실행되는 프로그램의 명령어와 데이터르 저장한다. 메모리에 저장된 값의 위치는 주소(address)로 알 수 있다. CPU CPU는 메모리에 저장된 값을 읽어 들이고, 해석하고, 실행하는 장치다. CPU 내부에는 ALU, 레지스터, 제어장치가 있다. ALU는 계산, 레지스터는 임시 저장, 제어장치는 제어 신호 발생 및 명령어 해석을 담당한다. 보조기억장치 메모리의 다음 단점들을 개선한 저장장치 가격이 비싸 저장 용량이 적음 전원이 꺼지면 저장된 내용을 잃음 입출력장치 컴퓨터 외부에 연결되어 컴퓨터 내부와 정보를 교환 키보드, 마우스 등 보조기억장치도 관점에 따라 입출력장치의 일종으로 볼 수 있다. 메인보드 마더보드 컴퓨터 부품을 연결하는 판 버스: 컴퓨터 내부의 통로 시스템 버스: 컴퓨터의 네 가지 핵심 부품이 정보를 서로 주고받는 통로 주소 버스: 주소 데이터 버스: 명령과 데이터 제어 버스: 제어 신호

12장 리소스 설명과 연결된 데이터 표현 전략(Representation Strategy) 클라이언트가 GET 요청을 리소스의 URL로 보내고 해당 리소스의 표현을 받는 것을 말한다. 리소스가 자기 자신에 대해 말 하는 것. 이 책에서 다룬 데이터 형식지금까지 이 책에선 이걸 허용했다. 설명 전략(description strategy) 표현의 리소스보다 다른 리소스들에 대해 말하는 것 RDF(Resource Description Framework) 리소스 설명 프레임워크 설명 전략에만 집중한 형식 그룹 어떤 리소스에 대해 누가, 무엇을, 어떻게 설명했는지 구조적으로 표현하는 방식 이걸 기계가 이해할 수 있는 방식으로 정리하는 것 ...

11장 API를 위한 HTTP WWW가 기술스택이라면 3단계로 나눌 수 있다. 맨 아래: URL, 리소스 리소스 위: HTTP 프로토콜, 리소스 표현을 읽는 권한한과 기본적인 리소스 상태에 쓰는 권한 맨 위: 하이퍼미디어, 하나의 웹 사이트나 API의 프로토콜 의미 체계 ⇒ 이 책에서 지금까지 다룬 것 새로운 HTTP1.1 설계 명세서 RFC 2616 HTTP 프로토콜 의미 체계를 명확히 하는 것 응답 코드 엔티티 바디는 응답 코드에 대한 설명(문제가 무엇인지)이 담겨야 한다. 200(OK)와 에러 메시지를 함께 보내지 마라. RFC 2616에 있는 것 외에 새로운 것을 정의히지 마라 헤더 RFC 2616에 있는 것 외에 새로운 것을 정의하지 마라 표현들 사이에서 선택하기 서버가 하나의 리소스에 대해 다양한 표현을 제공할 때 클라이언트가 이것들을 어떻게 구분해야 할까? ...

10장 하이퍼미디어 동물원 정말 다양한 하이퍼미디어 유형들이 있다. 이에 대해서 더 자세히, 기술적으로 알고 싶다면 해당 하이퍼미디어의 형식 명세서를 읽으면 된다. 도메인 특화 형식 Maze+XML: 미로게임 오픈서치(OpenSearch): 검색 쿼리 문제 상세 문서: 오류 조건을 설명 SVG: 이미지 형식, 벡터 그래픽 VoiceXML: 대화 말하기(음성 인식) 컬렉션 패턴 형식 Collection+JSON: 컬렉션과 아이템 AtomPub OData 필터링: 쿼리 언어를 사용하여 내재된 프로토콜 의미 체계의 집합을 정의 함수들과 메타데이터 문서 서비스 설명 문서로서 메타데이터 문서 순수 하이퍼미디어 유형 HTTP의 프로토콜 의미 체계를 표현하는 데 집중 HTML, HAL, 사이렌, Link 헤더, Location과 Content-Location 헤더, URL 목록, JSON 홈 문서,Link-Template 헤더, WADL, XLink, XForms, GeoJSON: 일반적인 하이퍼미디이 컨트롤, 미디어 유형이 없는 결함있음 의미 체계 동물원 연결 관계의 IANA 등록부 마이크로포맷 위키 hCalendar, hCard, XFN, XOXO,adr, geo, hAtom, hListing, hMedia, hNews, hProduct, hRecipe, hResume, hReview 등 마이크로포맷 위키의 연결 관계, schema.rog, 더블린 코어, 액티비티 스트림즈, ALPS 등록부

9장 설계 절차(1) 2단계 설계 절차 가장 단순한 형태 표현에 사용할 미디어 유형을 선택한다. 프로토콜 의미 체계(HTTP 프로토콜 하에서 API의 행동 양식)와 애플리케이션의 의미 체계(표현이 참조할 수 있는 실제 세계의 것들)에 제약 사항들을 결정 그 외 모든 것을 다루는 프로파일을 작성한다. JSON을 선택 ⇒ 프로토콜 애플리케이션 의미 체계에 아무런 제한이 없음 ⇒ 2에 모든 시간을 소비 7단계 설계 절차 API에서 클라이언트가 얻길 원하는 것이나 또는 API를 통해 넣길 원하는 모든 정버를 열거함 의미 체계 서술자 API를 나타내는 상태 다이어그램을 그림 연결 관계 기존에 있는 프로파일의 문자열을 이 API의 마법 문자열과 조정함 이 API의 프로토콜 의미 체계와 애플리케이션 의미 체계와 호환되는 미디어 유형을 선택하거나 새롭게 정의 애플리케이션 의미 체계를 기술하는 프로파일을 작성 코드 작성 광고판 URL 게시 미로 게임을 예시로 둔다. ...

8장 프로파일 현재까지 공부한 API 설계의 규칙 프로토콜 의미 체계의 문제 해결법 내 문제에 맞는 도메인 특화표준이 있다? ⇒ 사용 애플리케이션 특화 확장은 문서화 내 문제에 맞는 컬렉션 패턴이 있다? ⇒ 사용 애플리케이션 특화 용어를 정의하고 문서화 둘 다 해당되지 않으면? ⇒ 일반적인 하이퍼미디어 유형 사용 애플리케이션을 상태 전이로 나누고 문서화 애플리케이션 의미 체계의 문제 해결법 내 문제에 맞는 마이크로데이터 아이템이나 마이크로포맷이 있다? ⇒ 사용 문서화 없으면 애플리케이션 특화 용어를 정의 문서화 결국 문서화는 필요하다. ...

7장 순수 하이퍼미디어 설계 왜 HTML인가? HTML은 세상에서 가장 인기 있는 하이퍼미디어 유형이다. HTML의 기능 텍스트 문서의 중첩 구조를 표현할 수 있다. 택스트 콘텐트와 기타 태그를 표현할 수 있다. 하이퍼미디어 컨트롤 HTML은 다음과 같은 하이퍼미디어 컨트롤을 내장하고 있다. <link>, <a>, <img>, … 플러그인 애플리케이션 의미 체계 HTML은 사람이 이해할 수 있는 문서를 다룬다. HTML은 원래의 용도 외의 목적으로 사용하기가 매우 쉽다. HTML4는 세 가지 일반 속성을 더 가진다. rel : 연결되는 리소스와 지금 리소스 사이의 관계를 정의 id : 문서 내 한 요소를 식별하는 고윳값 class : 태그의 애플리케이션 의미 체계를 전달하는 용도(속하는 클래스를 정의) 마이크로포맷 hCard같은 마이크로포맷은 HTML에 추가적인 애플리케이션 의미 체계를 더하게 해준다. hMaze 마이크로포맷 새로운 hCard같은 마이크로포맷을 정의하는 것은 쉽다. 몇개의 클래스의 의미만 정의하면된다. 마이크로데이터 마이크로데이터는 HTML 5용으로 마이크로포맷을 다듬은 것이다. 다섯 개의 새로운 속성이 있다 itemprop : 마이크로포맷이 class 속성을 사용하던 방식으로 사용 itemscope : boolean. 태그에 마이크로데이터가 있는가를 표시 itemtype : 해당 마이크로데이터의 의미를 확인할 수 있는 곳 itemid itemref 마이크로포맷을 사용할땐 class=hCard 가 붙은 태그 내부가 모두 hcard 포맷임을 알 수 있다. 마이크로데이터는 그렇지 않다. itemscope 내부는 itemtype 이 가리키는 문서로 작성되어 있다고 표현된다. 예시 1 2 3 4 5 <div itemscope itemtype="https://www.naver.com/..."> <div itemprope="cell"> ... </div> </div> 마이크로포맷은 rel로 연결 관계를 정의할 수있지만 마이크로데이터는 그렇지 않다. itemtype 문서에는 나타날 것. 리소스 상태 변경하기 스위치를 누르면 리소스의 상태와 관계가 변경된다고 해보자 이 스위치를 조작하는 요청은 하이퍼미디어로 어떻게 구현될까? 폼에 애플리케이션 의미 체계 추가하기 rel 속성은 두 리소스 사이의 관계를 나타낸다. ‘리소스 상태를 변경하라’는 의미를 가진 rel 값을 만들 수 있을까? 리소스들이 나열되고 그 리소스를 요청하는 것은 GET 요청이다. 하지만 리소스 상태 변경은 GET 요청을 쓸 수 없다. POST를 써야한다. 이때 HTML이 정의한 하이퍼미디어 폼을 사용하면 된다. 대신, rel 속성은 지원하지 않는다. 이 switch 클래스도 hMaze 마이크로포맷에 추가할 수 있겠다. 1 2 3 <form action="/switches/4" method="post"> <input class="flip" type="submit" value="Flip it!"/> </form> 하이퍼미디어의 대체재는 미디어다 요즘 API 문서들에는 많은 메서드가 개별 API 호출로 노출되고, 상세하게 문서화되어 있다. 이는 다시 말해, 사람이 읽을 문서를 하이퍼미디어 대체재로 사용하고 있다는 것이다. 사람 대신, 이 정보를 받도록 의도된 대상(소프트웨어)에 맞춰 작성해야 한다. 스위치를 나타내는 두 버전을 살펴보자 1 2 3 4 스위치를 조작하려면 다음 주소로 POST 요청을 보낸다. https://api.example.com/swithches/{id}?action=flip {id}는 스위치 ID다. 스위치가 있는 셀에 있을 때에만 스위치를 조작할 수 있다. 1 2 3 4 5 6 7 <div class="swithch"> <span class="position">down</span> <form action="/swithches/4" method="post"> <inpuit class="flip" type="submit" /> </form> </span> </div> 애초에 하이퍼미디어 컨트롤을 사용할 수 있을 때만 제시되므로, 셀에 있을때에만 조작할 수 있다는 경고문구는 제공할 필요도 없다. HTML의 제약 기술적으로 HTML은 일반 하이퍼미디어 포맷이 아니라 도메인 특화 표준이다. 여기서 발생하는 한계들이 있다 PUT, DELETE는 HTML 하이퍼미디어 컨트롤로는 표현할 수 없다. HTML 4의 폼은 두 가지 종류의 엔티티 바디만 만들 수 있다. application/x-www-form-urlencoded multipart/form-data HTML 4는 JSON과 달리 숫자와 문자열을 구분하지 않는다. HTML 4는 날짜를 표시할 방법을 정의하지 않는다. HTML5가 문제를 해결해 줄까? 보완점 날짜 문제 ⇒ time 태그로 해결 숫자 문제 ⇒ 일반적으로 동작하지 않음 몇 가지 컨트롤을 더 정의하나, 여전히 유용하지 않음 input 태그 검증을 위한 방법 정의 일부는 보완되나, 하이퍼미디어 포맷으로서의 HTML을 급격히 변화시키지는 않는다. 하이퍼텍스트 애플리케이션 언어 웹 API에 특화되어 설계된, HTML의 기본 개념인 하이퍼링크만 가져온 HAL(Hypertext Application Language)가 있다. HAL은 두 가지 방식으로 제공된다. XML(application/hal+xml) JSON(application/hal+json) HTML과 HAL의 차이 HTML에는 여러가지 경우에 따라 <a>, <img>, <form> 을 사용한다. ...

6장 컬렉션 패턴 Collection+JSON은 여러 도메인에 걸쳐 반복해서 나타나는 패턴(컬렉션)을 다루기 위해 만들어졌다. 컬렉션은 무엇인가? 다른 리소스들의 링크를 걸어 나열하는 리소스다. 다른 리소스들을 한 그룹으로 묶는게 존재 목적이다. 아이템에 연결하는 컬렉션 아이템(item), 엔트리(entry), 멤버(member) : 컬렉션에 포함된 개별 리소르를 부르는 동의어 아이템이라해서 그 리소스 자체가 아니다. 친구 전화번호부의 콜렉션은 내가 아니다. Collection+JSON href: 컬렉션 자체의 영속적인 링크 items: 컬렉션 멤버를 가리키는 링크와 그것들의 부분 표현 links: 컬렉션에 관계된 다른 리소스를 연결한다. queries: 컬렉션 검색을 위한 하이퍼미디어 컨트롤 template: 컬렉션에 새 항목을 추가하기 위한 하이퍼미디어 컨트롤 아이템 표현하기 각 멤버는 JSON 객체로 표현된다. href 속성 : 해당 아이템을 독립 리소스로 나타내는 영속적인 링크 links:: 그 아이템에 연관된 다린 리소스의 하이퍼미디어 링크 data: 해당 아이템의 표현의 중요한 부분을 나타내는 기타 정보 아이템의 영속적인 링크 href 속성의 URL에 GET 요청을 보내면 서버는 한 아이템에 대한 Collection+JSON 표현을 보낸다. 아이템의 데이터 아이템의 data 슬롯에 JSON 객체 배열로 들어간다. name과 value 프로퍼티가 각각 단일 키-값 묶음을 나타낸다. 선택사항인 prompt는 사람이 이해할 수 있는 설명이다. 아이템의 링크 특정 아이템 하나를 참조하고 싶을 때 클라이언트가 사용할 특별할 URL이다. links라는 목록이 포함될 경우, 여기에 관련된 리소스를 연결하는 하이퍼미디어 링크 여러 개가 포함된다. 쓰기 템플릿 새 아이템을 컬렉션에 추가하려면 쓰기 템플릿에 적혀있는 형식으로, 컬렉션의 href로 POST 요청을 보내면 된다. 쓰기 템플릿은 개념적으로 HTML 폼과 동일하다. 동일한 입력을 하면 똑같은 요청을 보낸다는 의미다. 폼으로 보내면 application/x-www-form-urlencoded, 쓰기 템플릿으로 보내면 application/vnd,collection+json 일 뿐이다. 검색 템플릿 queries 슬롯에 저장된다. (일반) 컬렉션은 어떻게 동작하는가? GET 표현을 제공한다. 표현의 미디어 유형은 그 리소스로 무엇을 할 수 있는지 말해준다. application/vnd,collection+json : Collection+JSON 표준의 규칙 적용 application/atom+xml: AtomPub 규칙이 적용 applcation/json: 맘대로 하겠다. POST로 추가하기(POST-to-Append) 새 리소스를 생성 PUT과 PATCH 몇 개의 요소를 한 번에 수정하거나 개별 요소를 제거하는 데 사용 DELETE 무언가를 삭제하기 위해 존재 페이지 나눔 링크가 많을 경우 나눠서 제공한다. <link rel=”next” href=”/collection/4iz6”/> : 다음 next, previous, first, last, prev 등이 제공될 수 있다. 검색 폼 AtomPub(Atom Publishing Protocol) Collection+JSON의 item은 어떤것이든 나타날 수 있다. 반면 AtomPub은 뉴스 기사를 게시할 목적으로 설계되었다. 또한 뉴스 기사에 필요한 필드들이 존재한다. XML을 처리하는 방식때문에 도태됨 사람들은 자신이 필요로 하는 표준이 아니라면 해당 표준을 배우려 하지 않는다. 의미 체계의 문제: 잘 대응하고 있는가? 우리는 ‘컴퓨터가 어떤 링크를 클릭하도록 결정하게 하려면 어떻게 프로그래밍을 해야 할까?’에 대해 생각 중 컬렉션 패턴은 두 가지 다른 종류의 리소스를 인식한다 ⇒ 아이템 유형 리소스 : GET, PUT, DELETE에 응답 컬렉션 유형 리소스 : GET, POST에 응답 컬렉션과 아이템의 차이점 : 의미체계에서 나온다. 컬렉션 패턴에서 어떤 행동을 하기 위해 무엇이 필요한지는 알 수 있다. 하지만 필요한 필드의 의미를 알기 위해선 여전히 설명이 필요하다.