매일 사용하면서도 헤깔리는 부분입니다.;;;
라이브러리는 뭐고? 프레임워크는 뭔가????

오늘도 짧게 정리하고 갈게용 ㅎㅎ

라이브러리 

라이브러리는 사용하는 애플리케이션 코드가 애플리케이션 흐름을 직접 제어함
단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용함


프레임워크

애플리케이션 코드가 프에임워크에 의해 사용됌
프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는방식
분명한 제어의 역전 개념이 적용되어 있어야 함


즉 애플리케이션의 Flow를 누가 쥐고 있느냐의 차이다.

프레임워크 = 제어의 흐름을 프레임워크가 가짐
라이브러리 = 제어의 흐름을 개발자(사용자)가 가짐


이것도 면접 질문인가?;;;; 요즘 정리해두는 게 다 왜 이런...ㅎㅎ 기본이라 정리하는 겁니다..

면접을 준비하고 있는 것은 아닙니다 ㅋ;


Session

- 특정 웹사이트에서 사용자가 머무르는 기간 또는 한 명의 사용자의 한번의 방문을 의미한다.

- Session에 관련된 데이터는 Server에 저장된다.

- 웹 브라우저의 캐시에 저장되어 브라우저가 닫히거나 서버에서 삭제시 사라진다.

- Cookie에 비해 보안성이 좋다.


Cookie

- 사용자 정보를 유지할 수 없다는 HTTP의 한계를 극복할 수 있는 방법

- 인터넷 웹 사이트의 방문 기록을 남겨 사용자와 웹 사이트 사이를 매개해 주는 정보이다.

- Cookie는 인터넷 사용자가 특정 웹서버에 접속할 때, 생성되는 개인 아이디와 비밀번호, 방문한 사이트의 정보를 담은 임시 파일로써,

  Server가 아닌 Client에 텍스트 파일로 저장되어 다음에 해당 웹서버를 찾을 경우 웹서버에서는 그가 누구인지 어떤 정보를 주로 찾았는지 등을 파악할 때 사용된다.


- Cookie는 Client PC에 저장되는 정보기 때문에, 다른 사용자에 의해서 임의로 변경이 가능하다.(정보 유출 가능, Session보다 보안성이 낮은 이유)

Q. 보안성이 낮은 Cookie 대신 Session을 사용하면 되는데 안하는 이유?


A. 모든 정보를 Session에 저장하면 Server의 메모리를 과도하게 사용하게 되어 Server에 무리가 감


WEB 개발자라면 기본적으로 알아야 하죠?ㅎㅎ

잘 정리해보십다



Get 방식

- 클라이언트에서 서버로 데이터를 전달할 때, 주소 뒤에 "이름"과 "값"이 결합된 스트링 형태로 전달

- 주소창에 쿼리 스트링이 그대로 보여지기 때문에 보안성이 떨어진다.

- 길이에 제한이 있다.(=전송 데이터의 한계가 있다.)

- Post방식보다 상대적으로 전송 속도가 빠르다.


Post 방식

- 일정 크기 이상의 데이터를 보내야 할 때 사용한다.

- 서버로 보내기 전에 인코딩하고, 전송 후 서버에서는 다시 디코딩 작업을 한다.

- 주소창에 전송하는 데이터의 정보가 노출되지 않아 Get방식에 비해 보안성이 높다.

- 속도가 Get방식보다 느리다.

- 쿼리스트링(문자열) 데이터 뿐만 아니라, 라디오 버튼, 텍스트 박스 같은 객체들의 값도 전송가능.


Get과 Post 차이점

- Get은 주로 웹 브라우저가 웹 서버에 데이터를 요청할 때 사용

- Post는 웹 브라우저가 웹 서버에 데이터를 전달하기 위해 사용.

- Get을 사용하면 웹 브라우저에서 웹 서버로 전달되는 데이터가 인코딩되어 URL에 붙는다.

- Post방식은 전달되는 데이터가 보이지 않는다.

- Get방식은 전달되는 데이터가 255개의 문자를 초과하면 문제가 발생할 수 있다.


- 웹서버에 많은 데이터를 전달하기 위해서는 Post 방식을 사용하는 것이 바람직하다.


Thread(쓰레드) - 프로세스내에서 동시에 실행되는 독립적인 실행 단위를 말함, 장점으로는 자원을 많이 사용하지 않고 구현이 쉬우며 범용성이 높다
                                   

Process(프로세스)운영체제에서 실행중인 하나의 프로그램(하나 이상의 쓰레드를 포함한다.)

Thread 장점

- 빠른 프로세스 생성

- 적은 메모리 사용

- 쉬운 정보 공유

Thread 단점

- 교착상태에 빠질 수 있다.

* 교착상태 - 다중프로그래밍 체제에서 하나 또는 그 이상의 프로세스가 수행 할 수 없는 어떤 특정시간을 기다리고 있는 상태.

Thread와 Process 차이

여러 분야에서 '과정' 또는 '처리'라는 뜻으로 사용되는 용어로 컴퓨터 분야에서는 '실행중인 프로그램'이라는 뜻으로 쓰인다. 


이 프로세스 내에서 실행되는 각각의 일을 스레드라고 한다. 프로세스 내에서 실행되는 세부 작업 단위로 여러 개의 스레드가 하나의 프로세스를 이루게 되는 것이다.


Thread와 Process의 차이부터 논해야 한다. Process와 Thread의 차이는 신입이나 사회 초년생 개발자들이라면 면접 때 한두번은 들어본 질문일 것이다.
Thread는 Process와 거의 유사하다. 단지 Thread는 컴퓨터의 자원, 예를들면 메모리와 IO 장치들을 Thread끼리 공유하고, Process는 독립적으로 OS로부터 할당받아 사용한다. 일반적으로 Process는 여러 Thread를 Invoking 시키고 관리한다. 어플리케이션이 실행될 때 한개의 Process가 발생을 하고 그 Process가 어떠한 일을 할 때 컴퓨터의 자원을 최대로 활용하기 위해서는 병렬적으로 일을 하게 만들어야 한다. 그러므로 Thread를 이용해서 컴퓨터의 놀고 있는 자원들을 최대한으로 사용하게 만드는 것이 Multi-Thread Programming의 영역이다. I/O를 기다리게 하지 않고 다른 일을 하게 하거나, 놀고 있는 여분의 CPU 코어들을 최대한 사용하게 하는 것이 핵심이다.
RestFul
(Representational State Transfer)

REST란?


HTTP URI를 통해 Resource를 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 Resource에 대한 CRUD Operation을 적용한다. 즉, REST는 ROA(Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.

HTTP Method와 CRUD Operation은 일반적으로 아래 표와 같이 맵핑된다.



2) SOAP와 비교


[일반적인 웹서비스]


[REST] URL로 요청



3) REST의 장점

- OPENAPI를 제공하기 쉽다.
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고받을수 있따. (XML, JSON, RSS )
- 기존 웹 인프라를(HTTP)를 그대로 사용가능하다 ( 방화벽, 장비 요건 불필요 )
- 사용하기 쉽다
- 세션을 사용하지 않는다. 각각의 요청에 독립적.

4) REST의 단점

- 표준이 없어서 관리가 어렵다.
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- 분산환경에는 부적합하다.
- HTTP통신 모델에 대해서만 지원한다.

5) REST의 특징

- 클라이언트/서버 구조 : 일관적으로 독립되어야 한다.
- 무상태(Stateless) : 각요청 간 클라이언트의 Context는 서버에 저장되어서는 안 된다.
- 캐시가능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 Caching 할 수 있어야 한다.
- 계층화(Layered System) : 클라이언트는 보통 대상 서버에 직접 연결 또는 중간 서버를 통     해 연결되는지 모른다.
- Code on demand(option) : 자바 애플릿/ 자바스크립의 제공으로 서버가 클라이언트가 실행   시킬 수 있는 로직을   전송하여, 기능을 확장 할수 있다.
- 인터페이스 일관성 : 아키텍처를 단순화하고, 작은 단위로 분리하여, 클라이언트-서버 파트    별로 독립적으로 개     선 될 수 있도록 한다.
- 자체 표현구조(Self-Descriptiveness) : API 메시지만 보고도 어떤 API인지를 이해 할수 있는 자체 표현 구조    를 가진다.

6) ROA란?

웹의 모든 리소스를 URI로 표현하고 구조적이고 유기적으로 연결하여 비 상태 지향적인 방법으로 정해진 method만을 사용하여 리소스를 사용하는 아키텍처
이는 4가지의 고유한 속성과 연관되어 진다. ( REST는 이 속성들을 지향한다 ) 

  - Addressablilty
  - Connectedness
  - Statelessness
 
 - Homogeneous Interface

+ Addressablilty (주소로 표현 가능함) 
- 제공하는 모든 정보를 URI로 표시할 수 있어야 한다.
- 직접 URI로 접근할 수 없고 HyperLink를 따라서만 해당 리소스에 접근할 수 있다면 이는 RESTful하지 않은 웹서비스이다.
 


+ Connectedness (연결됨) 
- 일반 웹 페이지처럼 하나의 리소스들은 서로 주변의 연관 리소스들과 연결되어 표현(Presentation)되어야 한다.
 - 예를 들면,
<user>
  <name>HJ</name>
</user> 는 연결되지 않은 독립적인 리소스이다.
<user>
  <name>HJ</name>
  <address>HJ/seoul/</address>
  <phone>HJ/010</phone>
</user> 는 관련 리소스(address, phone)가 잘 연결된 리소스의 표현이다.


+ Statelessness (상태 없음) 
- 현재 클라이언트의 상태를 절대로 서버에서 관리하지 않아야 한다.
- 모든 요청은 일회성의 성격을 가지며 이전의 요청에 영향을 받지 말아야 한다.
- 다시 또 코리아닷컴의 예를 들면 메일을 확인하기 위해 꼭 '..코리아닷컴../mailView.crd'에 접근하여 해당 세션을 유지한 상태에서 메일 리소스에 접근해야 한다. 이것이 바로 Statelessness가 없는 예이다.
 - 세션을 유지 하지 않기 때문에 서버 로드 발란싱이 매우 유리하다.
 - URI에 현재 state를 표현할 수 있어야 한다. (권장사항)

+ Homogeneous Interface (동일한 인터페이스)
 - HTTP에서 제공하는 기본적인 4가지의 method와 추가적인 2가지의 method를 이용해서 리소스의 모든 동작을 정의한다.
 - 리소스 조회 : GET
 - 새로운 리소스 생성 : PUT, POST (새로운 리소스의 URI를 생성하는 주체가 서버이면 POST를 사용)
 - 존재하는 리소스 변경 : PUT
 - 존재하는 리소스 삭제 : DELETE
 - 존재하는 리소스 메타데이터 보기 : HEAD
 - 존재하는 리소스의 지원 method 체크 : OPTION
 - 대부분의 리소스 조작은 위의 method를 이용하여 대부분 처리 가능하다. 만일 이것들로만 절대로 불가능한 액션이 필요할 경우에는 POST를 이용하여 추가 액션을 정의할 수 있다. (되도록 지양하자)



*  supplement

  • SOAP : HTTP, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜

* Reference
  • http://spoqa.github.io/2012/02/27/rest-introduction.html
  • https://slipp.net/wiki/pages/viewpage.action?pageId=12878219#id-8주차-RESTAPI설계및구현-REST
  • http://egloos.zum.com/killins/v/3092502
  • http://www.hoons.net/Lecture/View/391
  • http://www.seungdols.com/web/restful
  • https://ko.wikipedia.org/wiki/REST
  • http://www.iamcorean.net/22

URL =  Uniform Resource Locator (정형화 된 리소스 위치 표시라는 뜻)

단어의 뜻대로 해석하자면 예전에는 URL이 가리키는게 파일리소스 였는데

요즘은 Rewrite 등의 Apache , IIS, Tomcat 핸들러 때문에 자원 이라고 부른다.

 

즉 웹사이트 주소가 (http://test.com/adultdisease/diabetes) 라고 했을 때

요청하는 주소가 파일이라기 보다는 구분자로 보는 것이다.


실제로 해당 웹사이트의 adultdisease/diabetes 라는 파일은 없다.



URI =  Uniform Resource Identifier



이 말장난을 정리해보자면, URI는 자원을 식별할 수 있는 문자열정도로 생각하면 될 것 같다. URI가 가장 큰 개념이고 이것의 하위개념으로 URL과 URN이 있는것이다. 예를 들어 http://ko.wikipedia.org/ 라는 주소는 http://ko.wikipedia.org/라는 서버를 나타내기때문에 URL이면서 URI이다. http://sunychoi.github.io/java/2015/04/12/java-bigdecimal.html 라는 주소는 sunychoi.github.io 호스트 주소 하위에 java/2015/04/02라는 디렉토리아래 java-bigdecimal.html이라는 자원의 위치를 가리키고있으므로 URL이면서 URI이다.

그럼 URL이 아닌 URI는 뭘까?


https://www.google.co.kr/search?q=uri 아래와같은 주소가 있다고하자. https프로토콜을 가지고있고 호스트이름을 가지고있다. 하지만 그 뒤에 /search?q=uri와 같은 문자열이 붙은걸 알 수 있는데 이 아이는 query string인 q의 값에 따라 여러가지 결과값을 가져올 수 있다. 위 주소에서 URL은 https://www.google.co.kr/search까지이고, 내가 원하는 정보를 얻기위해서는 q=uri라는 식별자가 필요하므로, https://www.google.co.kr/search?q=uri 이 주소는 URI이지만 URL은 아니다.



URI(동물) 가 좀더 상위 개념이라서 URL(강아지), URN(다람쥐) 등의 하위 개념을 포함한다.

 

URI 와 URL 이 아예 다른게 아니라 포함관계라서

모든 URL 는 URI 이다. 가 성립힌다. (TRUE)


URI = URL + URN

'IT지식' 카테고리의 다른 글

라이브러리와 프레임워크의 차이  (0) 2016.12.01
session과 cookie  (0) 2016.11.24
Get방식과 Post 방식의 차이 및 장단점  (0) 2016.11.24
쓰레드와 프로세스의 차이 및 장단점  (0) 2016.11.24
RestFul이란  (0) 2016.11.24

+ Recent posts