라이선스란?

• 넓은 의미에서의 라이선스

  • 면허, 면허증
  • 특정한 일을 할 수 있는 자격을 행정기관에서 허가 하는 일

• 소프트웨어에서의 라이선스

  • 소프트웨어를 사용할 수 있는 권한 또는 사용을 허가한다는 내용을 담은 문서

Free Software License

• 공짜가 아닌 자유(금전적인 측면이 아님)
• 자유의 의미
  • 프로그램을 어떠한 목적을 위해서도 실행할 수 있는 자유
  • 프로그램의 작동 원리를 연구하고 이를 자신의 필요에 맞게 변경시킬 수 있는 자유
  • 이웃을 돕기 위해서 프로그램을 복제하고 배포할 수 있는 자유
  • 프로그램을 향상시키고 이를 공동체 전체의 이익을 위해서 다시 환원시킬 수 있는 자유

Free Software Foundation

• 1985 10월 4일 리처드 스톨만이 세움
• 소프트웨어의 자유로운 복사와 배포,개선을 촉진하기 위한 조직
• 주요 활동
  • 자유소프트웨어 철학 및 유지관리
  • 저작권을 가진 자유 소프트웨어의 보호
• http://www.fsf.org

라이선스 분류

• GPL 호환 자유소프트웨어 라이선스
  • GPL, LGPL, Apache 2.0 등등...
• GPL 비호환 자유소프트웨어 라이선스
  • Apache 1.0, BSD, MPL 등등…
• NonFree 소프트웨어 라이선스
  • Code Project License, JSON 등등…

라이선스 종류

GPL (The GNU General Public License)

• 자유소프트웨어재단에서 만든 라이선스로 GNU 프로젝트로 배포하는 소프트웨어에 적용하기 위하여 리처드스톨만이 만들었다.
• 오픈 소스들 중에서 많이 알려져 있고 의무사항들도 다른 오픈 소스 라이선스에 비해 엄격한 편이다.
• GPL프로그램은 어떤 목적으로, 어떤 형태로든 사용할 수 있지만 사용하거나 변경된 프로그램을 배포하는 경우 무조건 동일한 라이선스로 공개해야 하며. ”본 제품(SW)은 GPL 라이선스 하에 배포되는 SW인 ○○○ (사용한 GPL SW 이름)를 포함합니다”와 같은 문구를 매뉴얼 혹은 그에 준하는 매체에 포함시키고, GPL 전문을 첨부해야 한다.
• 컴퓨터 프로그램을 어떠한 목적으로든지 사용할 수 있다. 다만 법으로 제한하는 행위는 할 수 없다.
• 컴퓨터 프로그램의 실행 복사본은 언제나 프로그램의 소스 코드와 함께 판매하거나 소스코드를 무료로 배포해야 한다.
• 변경된 소스프로그램의 소스코드를 용도에 따라 변경 할 수 있다.
• 변경된 컴퓨터 프로그램 역시 프로그램의 소스코드를 반드시 공개 배포해야 한다.
• 변경된 프로그램 역시 반드시 똑같은 라이선스를 취해야 한다. 즉, GPL 라이선스를 적용해야 한다.

AGPL (Affero General Public License)

• GPL을 기반을 만든 라이선스로 버전 1, 2는 Affero, 버전 3은 자유소프트웨어재단에 의해 개발됐다.
• 이 라이선스는 수정한 소스코드를 서버에서만 사용하는 개발자가 그 프로그램을 배포하지 않을 경우 사용자는 소스코드를 가질 수가 없는 문제를 해결하기 위해 마련됐다.
• 서버에서 프로그램을 실행해 다른 사용자들과 통신하면, 실행되고 있는 프로그램의 소스코드를 사용자들이 다운로드할 수 있게 해야 한다는 조항을 담고 있다.

LGPL (The Lesser GNU General Public License)

• LGPL은 자유소프트웨어재단이 일부 라이브러리(Library)에 대하여 GPL보다 소스코드의 공개 정도를 다소 완화된 형태로 사용할 수 있도록 만든 라이선스이다. (GPL의 제약을 완화시킨 라이선스)
• 상용 라이브러리와 동일한 기능을 제공하는 오픈 소스 라이브러리에 GPL과 같은 엄격한 라이선스를 적용하면 소스코드를 공개해야 하기 때문에 개발자들이 사용을 꺼려할 것이기 때문에 이를 막고 오픈 소스의 사용을 장려하기 위해 만들어 졌다.
• LGPL이 적용된 라이브러리는 원 프로그램의 소스코드를 공개하지 않고 이에 사용된 오픈 소스의 소스코드만 공개하면 된다.
• 원래는 한정된 라이브러리에만 적용하려는 의도로 Library GPL이라는 이름을 붙였으나, 모든 라이브러리에 적용된다는 오해를 사 Lesser GPL로 2.1버전에서 변경되었다.
• LGPL 라이선스를 가지고 있는 라이브러리를 동적 링크할 경우 소스공개의 의무가 사라짐
• LGPL 라이선스 라이브러리를 수정시에는 수정된 라이브러리 소스는 공개해야 한다.
• 현재 GNU 재단에서 밀고 있다.

The BSD(Berkely Software Distribution) License

• BSD는 버클리의 캘리포니아 대학에서 배포하는 공개 SW라이선스로 SW의 소스코드를 공개하지 않아도 되는 대표적인 오픈 소스 SW의 라이선스 중 하나이다.
• 이렇게 BSD의 라이선스의 허영범위가 넓은 이유는 BSD라이선스로 배포되는 프로젝트가 미국 정부에서 제공한 재원으로 운영되었기 때문이다. (미국 공공기관에서 지원. 미국인의 세금으로 만들어진 소프트웨어)
• 즉, SW에 대한 대가를 미국 국민의 세금으로 미리 지불했기 때문에 사람들에게 그들이 원하는 방식으로 SW를 사용하거나 만들도록 허가된 것이다. (공공성을 강조)
• 따라서 BSD라이선스의 소스코드를 이용하여 새로운 프로그램을 개발하여도 새로운 프로그램의 소스코드를 공개하지 않고 BSD가 아닌 다른 라이선스를 적용하여 판매할 수 있다.(소스를 자유롭게 이용, 배포 가능)

MPL(Mozilla Public License)

• Mozilla 재단에서 MS Explorer 점유율 상승으로 Netscape 소스 공개 결정하고, GPL의 제약과 BSD의 불안감에 의해 새로운 라이선스의 개발했다.
• 프로그램의 자유로운 사용, 복제, 배포, 수정을 허용한다.
• MPL은 Netscape브라우저의 소스코드를 공개하기 위해 개발된 라이선스로 공개하여야 할 소스코드의 범위를 좀 더 명확하게 정의하고 있다.
• 즉, GPL에서는 링크되는 SW의 소스코드를 포함하여 공개하여야 할 소스코드의 범위가 모호하게 정의되어 있지만, MPL에서는 링크 등의 여부에 상관없이 원래의 소스코드가 아닌 새로운 파일에 작성된 소스코드에 대해서는 공개의 의무가 발생하지 않는다.
• 따라서 MPL SW 그 자체는 어떻게 하든 공개를 해야 하지만 원래 소스코드에 없던 새로운 파일들은 공개할 의무가 발생하지 않는다.

The Apache License, Version 2.0

• 아파치 소프트웨어 재단(Apache Software Foundation)에서 만든 규정이다.
• 아파치 웹 서버를 포함한 아파치 재단의 모든 SW에 적용되는 라이선스로 BSD라이선스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다.
• 다만 "Apache"라는 이름에 대한 상표권을 침해하지 않아야 한다라는 조항이 명시적으로 들어가 있고, 특허권에 대한 내용이 포함되어 있다.
• 아파치 라이선스 소스코드를 수정해 배포하는 경우 아파치 라이선스 버전 2.0을 꼭 포함시켜야 하며 아파치 재단에서 만든 소프트웨어임을 밝혀야 한다.
• 누구나 해당소프트웨어에서 파생된 프로그램 제작가능, 저작권 양도, 배포 가능이다.
• 소스 공개 의무 없음

The MIT License

• MIT는 미국 Massachusetts Institute of Technology에서 해당 대학 SW 공학도들을 돕기 위해 개발한 라이선스이다.
• 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스로, BSD라이선스를 기초로 작성되었으며 소스코드를 수정하여 배포 시에도 반드시 오픈 소스로 배포해야 한다는 규정이 없어 GPL등의 엄격함을 피하려는 사용자들에게 인기가 많다.

CPOL(The Code Project Open License)

CDDL (The Common Development and Distribution License)

Ms-PL (The Microsoft Public License)

MPL 1.1 (The Mozilla Public License 1.1)

CPL (The Common Public License Version 1.0)

The Eclipse Public License 1.0

The Creative Commons Attribution-ShareAlike 2.5 License

The zlib/libpng License

공개 커뮤니티에 대한 공헌 (라이선스 아님)

출처

• https://www.codeproject.com/info/Licenses.aspx
• http://www.fsf.org
• http://www.gnu.org
• http://www.olis.or.kr
• http://www.bloter.net/archives/209318

HTTP 응답 코드 종류

GET

GET 요청 방식은 URI(URL)가 가진 정보를 검색하기 위해 서버 측에 요청하는형태이다

전송 형태

GET [request-uri]?query_string
HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n

POST

POST 요청 방식은 요청 URI(URL)에 폼 입력을 처리하기 위해 구성한 서버 측 스크립트(ASP, PHP, JSP 등) 혹은 CGI 프로그램으로 구성되고 Form Action과 함께 전송되는데, 이때 헤더 정보에 포함되지 않고 데이터 부분에 요청 정보가 들어가게 된다.

전송 형태

POST [request-uri]?query_string
HTTP/1.1\r\n
HOST:[Hostname] 혹은 [IP] \r\n
Content-Lenght:[Lenght in Bytes] \r\n
\r\n
[query-string] 혹은 [데이터]

HEAD

HEAD 요청 방식은 GET과 유사한 방식이나 웹 서버에서 헤더 정보 이외에는 어떤 데이터도 보내지 않는다.
웹 서버의 다운 여부 점검(Health Check)이나 웹 서버 정보(버전 등)등을 얻기 위해 사용될 수 있다.

전송 형태

HEAD [request-uri] HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n

OPTIONS

해당 메소드를 통해 시스템에서 지원되는 메소드 종류를 확인할 수 있다.

전송 형태

OPTIONS [request-ri]
HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n

PUT

POST와 유사한 전송 구조를 가지기 때문에 헤더 이외에 메시지(데이터)가 함께 전송된다.
원격지 서버에 지정한 콘텐츠를 저장하기 위해 사용되며 홈페이지 변조에 많이 악용되고 있다.

전송 형태

PUT [request-uri] HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n
Content-Lenght:[Length in Bytes] \r\n
Content-Type:[Content Type] \r\n
\r\n
[데이터]

DELETE

원격지 웹 서버에 파일을 삭제하기 위해 사용되며 PUT과는 반대 개념의 메소드이다.

전송 형태

DELETE [request-uri] HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n
\r\n

TRACE

원격지 서버에 Loopback(루프백) 메시지를 호출하기 위해 사용된다.

전송 형태

TRACE [request-uri] HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n
\r\n

CONNECT

웹 서버에 프락시 기능을 요청할 때 사용된다.

전송 형태

CONNECT [request-uri] HTTP/1.1\r\n
Host:[Hostname] 혹은 [IP] \r\n
\r\n

YouTube에서 음악 등은 mp3로 다운받고 싶은 경우가 있을 것이다.

웹 검색을 해보면, 웹사이트에서 유투브 URL를 입력하여 다운 받는 사이트를 쉽게 찾을 수 있을 것이다. 

한두개는 쉽게 받을 수 있겠지만, 여러개 받아야 한다면? 일일이 다 하나씩 입력하고 다운받고, 웹상이다 보니 아무래도 속도도 느리고 불편하기도 하다.

그래서 웹사이트가 아닌 어플리케이션 프로그램을 추천 및 소개하고자 한다.

https://www.mediahuman.com/

이 프로그램을 이용하면 단순히 마우스로 URL를 끌어오는 것만으로 쉽게 다운로드 받을 수 있다.

여러개를 연속으로 계속 끌어 올 수도 있으며, 속도도 웹보다는 빠른 편이다.

위 이미지는 MacOS 버전이지만, 다운로드 페이지로 가면 윈도우 버전 뿐 아니라 리눅스 버전도 제공하고 있다.

https://www.mediahuman.com/download.html

REST는 Representational State Transfer라는 용어의 약자로서 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표하였다.

필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

REST 의 특징

1. Uniform Interface (유니폼 인터페이스) 
   Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다. 쉽게 말하자면 시스템 REST API를 정의했다면, 안드로이드나 iOS 플랫폼 상관 없이, 또는 C/C++, Java, Python 등의 특정 언어나 기술에 종속 받지 않고 HTTP를 사용할 수 있는 모든 플랫폼에 사용이 가능한 느슨한 결함(Loosely coupling) 형태의 구조이다.

2. Stateless (무상태성) 
   REST는 무상태성 성격을 갖는다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

3. Cacheable (캐시 가능) 
   REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

4. Client - Server 구조 
   REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.

5. Self-descriptiveness (자체 표현 구조) 
   REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.

6. Layered System(계층형 구조) 
   REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

7. Code on demand (optional) 
   자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.

REST 구성 요소

Resource (자원)

REST에서 가장 중요한 개념은 바로 유일한 ID를 가지는 Resource가 서버에 존재하고, 클라이언트는 각 Resource의 상태를 조작 및 조회를 하기 위해 요청을 보낸다. 일반적으로 Resource의 예로는 user, group 등과 같은 명사형의 단어이고, HTTP에서 이러한 Resource 를 구별하기 위한 ID는 'groups/{groupId}/users/{userId}'와 같은 URI을 뜻한다.

Method (행위)

Resource를 조작할 수 있는 동사형의 단어를 Method라고 한다. 클라이언트는 URI를 이용해서 Resource를 지정하고 해당 Resource를 조작 및 조회를 하기 위해서 Method를 사용한다. HTTP에서는 GET, POST, PUT, DELETE 등의 Method를 제공한다.

Representation of Resource (표현되는 자원)

클라이언트가 서버로 요청을 보냈을 때, 서버가 응답으로 보내주는 Resource의 형태를 Representation이라고 한다. REST에서 하나의 Resource는 여러 형태의 Representation으로 나타내어 질 수 있다. 예를 들어 xml, json, text, rss 등으로 전달된다.

HTTP Methods

HTTP 에는 여러가지 Method가 있지만 REST에서는 CRUD(Create Read Update Delete)에 해당 하는 4가지의 메서드만 사용한다.

Resource Naming (자원 명명 규칙)

자원에 대한 명명 규칙은 HTTP Method(GET, POST, PUT, DELETE 등)를 적절하게 활용하는 것 외에도 이해하기 쉽게 활용되는 웹 서비스 API를 만들 때 가장 많이 논의되기도 하고 중요한 개념이다. 자원의 이름이 정해진 API는 직관적이며 사용하기 쉽다.

REST에서 중요한 항목 2가지가 있다.

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.

URI는 리소스만 표현하고, 자원에 대한 행위는 HTTP Methods을 표현한다.

리소스명은 동사보다는 명사를 사용하고, 행위(create, update delete 등)의 행위 포함하지 않는다.

• GET : users/update/1 (X)
• PUT : users/1 (O)

첫번째 경우는 REST를 제대로 적용하지 않은 URI이다. URI는 자원을 표현하는데 중점을 두어야 한다. update와 같은 행위에 대한 표현이 들어가서는 안된다. 사용자 정보 편집을 위한 API라면 PUT을 사용한다.

URI에 리소스명은 복수로 표현한다.

계층 구조의 URI 노드는 복수 명사를 사용한다.

• GET /user/329 (X)
• GET /users/329 (O)

위에 두개는 논란이 있긴 하지만 일반적으로 인정되는 관례는 노드 이름에 항상 복수형을 사용하여 모든 HTTP 메소드에서 API URI를 일관성있게 유지하는 것이다. 이 추론은 사용자 목록 이고 ID(예:329)가 목록중에 있는 사용자 하나를 참조하는 개념을 기반으로 한다.

URI에 파일 확장자는 포함시키지 않는다.

• GET : /users/345/profile.jpg (X)
• GET : /users/345/profile - HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)

REST API에서는 Request Body 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. Accept header를 사용한다.

URI에 슬래시(/) 구분자

슬래시 구분자(/) 계층 관계를 나타내는 데 사용하고 URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

• /users/{userid}/books/ (X)
• /users/{userid}/books (0)

리소스 간의 관계를 표현하는 방법

REST 리소스간에는 서로 연관관계가 있을 수 있다. 예를 들면 사용자의 친구들 목록을 표현하는 경우, 사용자가 소유하고 있는 책의 목록 들을 표현이 필요한 경우가 있다.

1. 서브 리소스로 표현하는 방법 (일반적으로 소유 ‘has’의 관계를 표현할 경우)
   • /users/{userid}/friends : 사용자의 친구 목록을 표현
   • /users/{userid}/books : 사용자가 소유하고 있는 책의 목록을 표현
2. 서브 리소스에 관계를 명시 하는 방법 (관계명이 애매하거나 구체적 표현이 필요할 경우)
   • /users/{userid}/recommand/books : 사용자 추천하는 책 목록

위에 1, 2은 어느것을 사용해도 좋으나 관계를 확실히 할 경우에는 2번을 사용해도 된다.

URI은 소문자가 적합하다.

URI 경로에 대문자 사용은 피하도록 한다. 대소문자에 따라 다른 리소스로 인식하게 되기 때문이다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정한다.

• /Users/{userid}/Books (X)
• /users/{userid}/books (O)

HTTP Status Codes(응답 상태 코드)

잘 설계된 REST API는 URI뿐만 아니라 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 중요하다. 혹시 성공 200이나 500 관련 특정 코드 정도만 사용하고 있다면 처리 상태에 대한 좀 더 명확한 상태코드 값을 사용하도록 한다. REST에서 꼭 필요한 상태코드에 아래와 같다.

2xx Success

3xx Redirection

4xx Client Error

5xx Server Error

참조

• https://ko.wikipedia.org/wiki/REST
• https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C
• https://books.google.co.kr/books?id=knLJCQAAQBAJ
• http://www.restapitutorial.com/lessons/restfulresourcenaming.html
• http://bcho.tistory.com/953