라이선스란?

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

    • 면허, 면허증
    • 특정한 일을 할 수 있는 자격을 행정기관에서 허가 하는 일
  • 소프트웨어에서의 라이선스

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

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

항목여부
저작권 보호
상용 소프트웨어에서 사용 가능
버그 패치 및 기능 확장 제공의 의무아니오
명시적 특허권 행사 가능 여부아니오
사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부
라이선스 전파 여부아니오

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

항목여부
저작권 보호아니오
상용 소프트웨어에서 사용 가능
버그 패치 및 기능 확장 제공의 의무아니오
명시적 특허권 행사 가능 여부아니오
사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부
라이선스 전파 여부아니오

출처


'기타' 카테고리의 다른 글

소프트웨어 라이선스  (0) 2019.03.17
HTTP 응답 코드 및 메소드  (0) 2018.11.06
YouTube to MP3 - 유투브 MP3 다운받기  (0) 2018.10.27
C/C++와 JAVA 비교  (0) 2018.01.10
REST API란?  (0) 2017.12.10
JSON이란?  (0) 2017.12.10

HTTP란?

HTTP(HyperText Transfer Protocol)는 WWW 상에서 정보를 주고받을 수 있는 프로토콜이다.


HTTP 응답 코드 종류

응답코드

의미설명
100Continue클라이언트로 부터 일부 요청을 받았으며 나머지 정보를 계속 요청함
101Switching protocols프로토콜 전환. 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
200OK요청이 성공적으로 수행되었음
201Created성공적으로 요청되었으며 서버가 새 리소스를 작성했음
202Accepted웹 서버가 요청을 접수했지만 아직 처리하지 않음
203Non-authoritative information신뢰할 수 없는 정보, 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있음
204No content콘텐츠 없음. 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않음
205Reset Content, 콘텐츠 재설정 - 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않음
206Partial content일부 콘텐츠. 서버가 GET요청의 일부만 성공적으로 처리했음
301Moved permanently요구한 데이터를 변경된 타 URL에 요청함
302Not temporarily
304Not modified컴퓨터 로컬의 캐시 정보를 이용함, 대개 gif 등은 웹 서버에 요청하지 않음
400Bad request사용자의 잘못된 요청을 처리할 수 없음
401Unauthorized인증이 필요한 페이지를 요청한 경우
402Payment required예약됨
403Forbidden접근 금지, 디렉터리 리스팅 요청 및 관리자 페이지 접근 등을 차단)
404Not found요청한 페이지 없음
405Method not allowed허용되지 않는 http method 사용함
407Proxy authentication required프락시 인증 요구됨
408Request timeout요청 시간 초과
410Gone영구적으로 사용 금지
412Precondition failed전체 조건 실패
414Request-URI too long요청 URL 길이가 긴 경우임
500Internal server error내부 서버 오류
501Not implemented웹 서버가 처리할 수 없음
503Service unnailable서비스 제공 불가
504Gateway timeout게이트웨이 시간 초과
505HTTP version not supported해당 http 버전 지원되지 않음



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

'기타' 카테고리의 다른 글

소프트웨어 라이선스  (0) 2019.03.17
HTTP 응답 코드 및 메소드  (0) 2018.11.06
YouTube to MP3 - 유투브 MP3 다운받기  (0) 2018.10.27
C/C++와 JAVA 비교  (0) 2018.01.10
REST API란?  (0) 2017.12.10
JSON이란?  (0) 2017.12.10

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

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

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


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

https://www.mediahuman.com/

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

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

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

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

'기타' 카테고리의 다른 글

소프트웨어 라이선스  (0) 2019.03.17
HTTP 응답 코드 및 메소드  (0) 2018.11.06
YouTube to MP3 - 유투브 MP3 다운받기  (0) 2018.10.27
C/C++와 JAVA 비교  (0) 2018.01.10
REST API란?  (0) 2017.12.10
JSON이란?  (0) 2017.12.10

C/C++와 Java를 비교해보면 아래와 같다.

구분CC++JAVA
#typedefOOX
#defineOOX
#gotoOOX
struct(구조체) 자료형OOX
Union 자료형OOX
데이터형 변환묵시적명시적랩퍼 클래스
배열포인터포인터객체
문자열배열배열String 자료형
메모리 관리수동수동자동
객체지향 개념비 객체지향 (절차 지향)반 객체지향객체지향
연산자 오버로딩XOX
함수(메소드) 오버로딩XOO
다중 상속XOX
운영체제 독립성XX비종속

main function

모든 프로그램들은 최초 실행 때에 시작 진입점을 가지게 되는데 C++에서는 main 함수가 되며 Java에서도 동일한 이름의 main 메소드가 프로그램의 진입점이 된다.

예제 1-1)과 예제 1-2)를 비교해보면 약간의 모양은 다른 부분이 있지만 거의 비슷해 보인다.

예제 1-1) C++ main function

#include <iostream>

int main(int argc, const char * argv[])
{
    std::cout << "Hello, World!\n";
    return 0;
}

예제 1-2) 자바 main method

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello world");
    }
}

C/C++의 main과 Java의 main을 비교해보면 아래와 같다.

구분C/C++Java
returnintvoid
prameterint argc, const char * argv[]String[] args
위치클래스 밖에 있다.클래스 안에 있다.

C/C++은 return은 보통은 정수인데 컴파일러에 따라 void도 존재한다. prameter도 맞찮가지로 컴파일러에 따라 없을 수도 있다.

프로그램 안에 main은 자바에 달리 클래스 밖에 존재하는데 이는 모든 것을 객체화한다는 객체 지향 언어 프로그래밍(object-oriented programing)에 위배된다고 하여 완벽한 객체 지향 언어가 아닌 반 객체 지향이라고도 한다.

define 메크로

C/C++와 비교해 Java에 없는 것중에 하나는 전처리문이다. 그 중 define에 대해서 설명한다.

define은 일명 메크로라고도 하는데 값, 함수를 지정한 것을 대체 치환해 주어 프로그래밍을 편하게 해준다. 여기서 치환해 준다는 말은 C++ 컴파일은 Java와 달리 전처리라는 소스 치환 과정을 있는데 실제 소스에 define된 값을 실제 값, 함수로 변환해주는 과정이다.

예제2-1)와 예제2-2)를 전처리 전후를 비교하면서 보자.

예제2-1) C++ 소스 코드

#include <iostream>

#define HELLO "Hello, World!\n"
#define MAX(a,b) ( (a) > (b) ? (a) : (b) )

int main(int argc, const char * argv[])
{
    std::cout << HELLO;
    std::cout << "Max:" << MAX(10, 100);
    return 0;
}

예제2-2) C++ 전처리 후의 소스 코드

# 1 "main.cpp"
# 1 "<built-in>"

... 중간생략 ...

# 10 "main.cpp" 2

int main(int argc, const char * argv[])
{
    std::cout << "Hello, World!\n";
    std::cout << "Max:" << ( (10) > (100) ? (10) : (100) );
    return 0;
}

전처리 파일을 컴파일마다 다르게 보일 수 있다. 예제는 g++로 만든 전처리 파일이다.

위에 소스를 보면 메크로 값 HELLO와 메크로 함수 MAX(a, b)에 주목하자. 개발자가 작성한 소스 파일이 전처리 과정을 거치고 HELLO는 실제 값인 "Hello, World!\n"이 들어가고 MAX(a, b) 은 ( (10) > (100) ? (10) : (100) )으로 변경된 것을 볼수 있다.

그럼 Java에서는 define인 아예 없는 것인가? 대답은 "그렇다"이다. 하지만 값 치환은 비슷하게 코드를 만들 수는 있다. 예제2-3)을 보자.

예제2-3) Java 소스 코드

public class Main {

    public static final String HELLO = "Hello, World!\n";

    public static void main(String[] args) {
        System.out.println(HELLO);
    }
}

예제2-3) Java 소스 코드는 HELLO 변수에 static, final로 지정하고 값을 대입하여 이를 출력하도록 했다. 이 소스를 컴파일하면 바이트 코드가 나오고 이를 다시 역컴파일 하면 C++의 define문과 비슷하게 치환되어 나오는걸 볼수 있다.

예제2-3) Java 역컴파일

public class Main
{

    public Main()
    {
    }

    public static void main(String args[])
   {
        System.out.println("Hello, World!\n");
    }

    public static final String HELLO = "Hello, World!\n";
}

실제로 예제2-3)가 역컴파일을 한 것이다. println에 넣었던 HELLO는 사라지고 실제 값인 "Hello, World!\n"이 들어가 있는 것을 확인 할수 있다.

이렇게 C++나 Java에서 치환되는 것이 실제 프로그램이 구동할 때 메모리에 관리되는 변수보다는 실제값이 직접 들어가게 되므로 아주 조금은 속도가 향상될 것으로 생각된다. 하지만 이 속도가 너무나 미세하기에 단순히 프로그램의 속도 향상을 위한 목적이라면 define을 쓰지는 말길 바란다. 오히려 너무 난발하면 디버깅이 힘든 프로그램이 되기에 주의를 요한다.

Tip)

Effective C++책의 항목2에서는 define의 사용보다는 const, enum, inline 함수 사용을 권장한다. 원인은 나중에 문제가 발생할 때 코드를 디버깅하기가 힘들기 때문이다. 너무나 중요한 로직 부분이나 디버깅이 힘들수 있게다고 생각된다면 define은 쓰지말길 바란다.



'기타' 카테고리의 다른 글

HTTP 응답 코드 및 메소드  (0) 2018.11.06
YouTube to MP3 - 유투브 MP3 다운받기  (0) 2018.10.27
C/C++와 JAVA 비교  (0) 2018.01.10
REST API란?  (0) 2017.12.10
JSON이란?  (0) 2017.12.10
마크다운(Markdown) 이란?  (0) 2017.12.10

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가지의 메서드만 사용한다.

HTTP VerbCRUDEntire Collection (e.g. /customers)Specific Item (e.g. /customers/{id})
POSTCreate201 (Created), 'Location' header with link to /customers/{id} containing new ID.404 (Not Found), 409 (Conflict) if resource already exists..
GETRead200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists.200 (OK), single customer. 404 (Not Found), if ID not found or invalid
PUTUpdate/Replace405 (Method Not Allowed), unless you want to update/replace every resource in the entire collection.200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
DELETEDelete405 (Method Not Allowed), unless you want to delete the whole collection—not often desirable.200 (OK). 404 (Not Found), if ID not found or invalid.

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

코드설명
200 OK서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
201 Created성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
204 No Content서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.

3xx Redirection

코드설명
304 Not Modified마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.

4xx Client Error

코드설명
400 Bad Request서버가 요청의 구문을 인식하지 못했다.
401 Unauthorized이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
403 Forbidden서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
404 Not Found서버가 요청한 페이지를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.

5xx Server Error

코드설명
500 Internal Server Error서버에 오류가 발생하여 요청을 수행할 수 없다.

참조


'기타' 카테고리의 다른 글

YouTube to MP3 - 유투브 MP3 다운받기  (0) 2018.10.27
C/C++와 JAVA 비교  (0) 2018.01.10
REST API란?  (0) 2017.12.10
JSON이란?  (0) 2017.12.10
마크다운(Markdown) 이란?  (0) 2017.12.10
문자열 체크 예제  (0) 2016.04.18

+ Recent posts