[SOLVED] Why two queries in Relationships, not join ? – Laravel.IO – The Official Laravel PHP Framework Community Portal

javascript – event.preventDefault() vs. return false – Stack Overflow

http status code 302 Redirect vs. 301 Redirect: Which is Better? » by Jonathan Hochman

http://blog.naver.com/PostView.nhn?blogId=tttnnn1234&logNo=110091727476 에서 참조

URI와 URL의 차이

Uniform Resource Identifier (URI) consists of a string of characters used to identify or name a resource on the Internet
http://en.wikipedia.org/wiki/URI

URI는 인터넷 상의 자원을 식별하기 위한 문자열의 구성쯤으로 해석 될 수 있겠다.

http://en.wikipedia.org/wiki/URL
URI의 한 형태인 URL은 인터넷 상의 자원 위치를 나타낸다.

URL는 URI의 한 형태로, 바꿔 말하면 URI는 URL을 포함 하는 개념이다.
(URI > URL)

인터넷 상의 자원의 위치와 식별자.
언듯 보면 같은 것을 의미하는 듯 하다.
하지만 ‘자원의 위치’라는 것은 결국은 ‘하나의 파일 위치’를 나타내는 것임을 명심하자.

http://img0.gmodules.com/ig/images/korea/logo.gif
이와 같은 형식은 logo.gif라는 인터넷상의 자원 위치를 의미 한다.
이는 URI이면서도 URL라고 말할 수 있다.

다음은 어떠한가.
http://endic.naver.com/endic.nhn?docid=1232950
http://endic.naver.com/란 서버에 위치한 endic.nhn파일은 query string인 docid의 값에 따라 여러가지 결과를 나타낸다.

여기서 URL은 endic.nhn의 위치를 표기한 http://endic.naver.com/endic.nhn 까지이다.
내가 원하는 정보에 도달 하기위해서는 ?docid=1232950라는 식별자(Identifier)가 필요한 것이다.

결국 위의 http://endic.naver.com/endic.nhn?docid=1232950주소는 URI이긴 하지만 URL은 아니다

[출처] URI 와 URL의 차이|작성자 너부리

URI 가 더 큰 개념이라고 할 수 있죠..
URI는 Uniform Resource Identifier 의 약자로
URL(Uniform Resource Locator)와 URN(Uniform Resource Name) 을 포함합니다.

아래의 자세한 내용은 http://www.xmlgo.net/open_xml/namespace/uri-url-urn.html 에서 발췌한 내용입니다. 참고하세요..

URLs

URL은 실제의 네트웍 경로를 가리키며, 네트웍 상의 리소스 접근시에 사용된다 URL의 첫 번째 부분은 다음과 같은 프로토콜을 명시하는데, 대부분의 경우 http이며, 가끔은 ftp 혹은 mailto이며, 드물게 gopher, news, telnet, file 등을 사용합니다. 이와 같은 URL 프로토콜 부분을 scheme이라고 한다. Scheme 뒤에는 콜론(:)이 따라오며 그 뒤에 식별된 자원의 경로가 나타난다. 다음의 예는 여러 분들이 매우 익숙할 것이다.

    http://www.xmlgo.net/document/editor/editor.html

이 URL은 www.xmlgo.net 이라는 이름의 인터넷 상에 있는 서버로부터 /document/editor/editor.html 이라는 파일을 검색하기 위하여 사용될 수 있는 경로(PATH)를 나타낸다. 파일 editor.html 은 /document/editor 이라는 디렉토리에 있으며, HTTP 프로토콜에 의하여 검색되야함을 명시한다. 또 다른 예로써 다음과 같은 전자메일 계정을 가리키는 URL도 있다.

    mailto:someone@sungshin.ac.kr

계속해서 다양한 프로토콜에 따른 예를 들어 본다면 ,

  • file -시스템내의 파일 이름 ( file:///C:windowsxmltest.xml )

  • ftp – ( ftp://ftp.is.co.za/rfc/rfc2141.txt )

  • news – 유즈넷 뉴스 그룹 ( news:comp.xml.xsl )

  • telnet – telnet://www.xmlgo.net

물론 URL을 통하여 검색될 수 있는 자원에는 제한이 있다. 컴퓨터로부터 검색가능한 형태의 자원만 검색할 수 있다. 실제의 예를 든다면 , RDF (URI상의,리소스에 관해 기술하는 규칙) : http://www.w3.org/TR/REC-rdf-syntax# SVG (2차원 그래픽,벡터형태의 그래픽, 이미지, 텍스트를 포함,을 표현하는 XML 용어집): http://www.w3c.org/XSL/Format/1.0 등이 네임스페이스로 사용된다.

URNs

URN은 자원에 대하여 영속적 (persistent)이고 유일하다. 위치에 독립적인 이름을 제공하기 위하여 존재한다. 이것은 RFC 2141 (http://www.ietf.org/rfc/rfc2141.txt) 에 정의되어 있다.

iURN은 문자열 “urn” 혹은 “URN”, NID (Namespace Identifier), 그리고 NSS (Namespace Specific String)로 구성되어 있으며 각 구성 엘리먼트간에 콜론(:)을 위치시킨다. NID는 URN의 형태를 나타내는데, 예를 들어 차후 XMLgo.net에서 ebXML문서의 형태로 각 회사의 정보를 기억해 두는 저장소를 URN으로 가리키고 , NSS 는 유일하고 영속적이여야 하며, 여기서는 registry1이라고 칭하였다.

    urn:xmlgo:registry1

좀더 현실적인 예를 들어 본다면

한국인을 위한 URN을 만들기 위하여 한국-시민 이라고 선언할 수 있다. NSS 로는 유일한 번호, 주민등록 번호를 표현하도록 한다면 000000-0000000 이 될 것이다.

    urn:한국-시민:000000-0000000

지금까지의 내용을 종합해 보면, Namespace를 지정할 때 URI 로 지정한다. URI로는 현재 널리 사용하는 웹주소, URL 방식과 URN 방식이 포함 되어 있다. 일반적으로 URL을 많이 사용하나 URN도 널리 사용 될 것이다. URL에서는 도메인 주소와 거기에 위치한 물리적인 경로가 자원을 찾기 위한 중요한 정보가 되지만, URN은 자원에 부여된 고유한 이름으로 그 자원의 위치와는 무관하게 부여된 이름이다.

이를 구체적으로 예를 들면 , 인천 광역시 남구 용현동에 인하대학교가 있지만, 인하대학교는 새로운 부지로 이사를 갈 수도 있을 것이다. 인하대학교가 어디에 있는지는 URL(주소)로 표현 할 수 있지만, 인하대학교가 다른 곳으로 가더라도 URN을 가지고 그 리소스(인하대학교)을 식별할 수 있다. 이사를 가고 나서 ‘인천광역시 남구 용현동의 인하대학교’ 라는 기존의 주소를 가지고는 인하대학교를 찾을 수 없다. 하지만 인하대학교란 고유한 이름은 변함이 없을 것이다

http://blog.naver.com/PostView.nhn?blogId=tttnnn1234&logNo=110091727476 에서 참조

URI와 URL의 차이

Uniform Resource Identifier (URI) consists of a string of characters used to identify or name a resource on the Internet
http://en.wikipedia.org/wiki/URI

URI는 인터넷 상의 자원을 식별하기 위한 문자열의 구성쯤으로 해석 될 수 있겠다.

http://en.wikipedia.org/wiki/URL
URI의 한 형태인 URL은 인터넷 상의 자원 위치를 나타낸다.

URL는 URI의 한 형태로, 바꿔 말하면 URI는 URL을 포함 하는 개념이다.
(URI > URL)

인터넷 상의 자원의 위치와 식별자.
언듯 보면 같은 것을 의미하는 듯 하다.
하지만 ‘자원의 위치’라는 것은 결국은 ‘하나의 파일 위치’를 나타내는 것임을 명심하자.

http://img0.gmodules.com/ig/images/korea/logo.gif
이와 같은 형식은 logo.gif라는 인터넷상의 자원 위치를 의미 한다.
이는 URI이면서도 URL라고 말할 수 있다.

다음은 어떠한가.
http://endic.naver.com/endic.nhn?docid=1232950
http://endic.naver.com/란 서버에 위치한 endic.nhn파일은 query string인 docid의 값에 따라 여러가지 결과를 나타낸다.

여기서 URL은 endic.nhn의 위치를 표기한 http://endic.naver.com/endic.nhn 까지이다.
내가 원하는 정보에 도달 하기위해서는 ?docid=1232950라는 식별자(Identifier)가 필요한 것이다.

결국 위의 http://endic.naver.com/endic.nhn?docid=1232950주소는 URI이긴 하지만 URL은 아니다

[출처] URI 와 URL의 차이|작성자 너부리

URI 가 더 큰 개념이라고 할 수 있죠..
URI는 Uniform Resource Identifier 의 약자로
URL(Uniform Resource Locator)와 URN(Uniform Resource Name) 을 포함합니다.

아래의 자세한 내용은 http://www.xmlgo.net/open_xml/namespace/uri-url-urn.html 에서 발췌한 내용입니다. 참고하세요..

URLs

URL은 실제의 네트웍 경로를 가리키며, 네트웍 상의 리소스 접근시에 사용된다 URL의 첫 번째 부분은 다음과 같은 프로토콜을 명시하는데, 대부분의 경우 http이며, 가끔은 ftp 혹은 mailto이며, 드물게 gopher, news, telnet, file 등을 사용합니다. 이와 같은 URL 프로토콜 부분을 scheme이라고 한다. Scheme 뒤에는 콜론(:)이 따라오며 그 뒤에 식별된 자원의 경로가 나타난다. 다음의 예는 여러 분들이 매우 익숙할 것이다.

    http://www.xmlgo.net/document/editor/editor.html

이 URL은 www.xmlgo.net 이라는 이름의 인터넷 상에 있는 서버로부터 /document/editor/editor.html 이라는 파일을 검색하기 위하여 사용될 수 있는 경로(PATH)를 나타낸다. 파일 editor.html 은 /document/editor 이라는 디렉토리에 있으며, HTTP 프로토콜에 의하여 검색되야함을 명시한다. 또 다른 예로써 다음과 같은 전자메일 계정을 가리키는 URL도 있다.

    mailto:someone@sungshin.ac.kr

계속해서 다양한 프로토콜에 따른 예를 들어 본다면 ,

  • file -시스템내의 파일 이름 ( file:///C:windowsxmltest.xml )

  • ftp – ( ftp://ftp.is.co.za/rfc/rfc2141.txt )

  • news – 유즈넷 뉴스 그룹 ( news:comp.xml.xsl )

  • telnet – telnet://www.xmlgo.net

물론 URL을 통하여 검색될 수 있는 자원에는 제한이 있다. 컴퓨터로부터 검색가능한 형태의 자원만 검색할 수 있다. 실제의 예를 든다면 , RDF (URI상의,리소스에 관해 기술하는 규칙) : http://www.w3.org/TR/REC-rdf-syntax# SVG (2차원 그래픽,벡터형태의 그래픽, 이미지, 텍스트를 포함,을 표현하는 XML 용어집): http://www.w3c.org/XSL/Format/1.0 등이 네임스페이스로 사용된다.

URNs

URN은 자원에 대하여 영속적 (persistent)이고 유일하다. 위치에 독립적인 이름을 제공하기 위하여 존재한다. 이것은 RFC 2141 (http://www.ietf.org/rfc/rfc2141.txt) 에 정의되어 있다.

iURN은 문자열 “urn” 혹은 “URN”, NID (Namespace Identifier), 그리고 NSS (Namespace Specific String)로 구성되어 있으며 각 구성 엘리먼트간에 콜론(:)을 위치시킨다. NID는 URN의 형태를 나타내는데, 예를 들어 차후 XMLgo.net에서 ebXML문서의 형태로 각 회사의 정보를 기억해 두는 저장소를 URN으로 가리키고 , NSS 는 유일하고 영속적이여야 하며, 여기서는 registry1이라고 칭하였다.

    urn:xmlgo:registry1

좀더 현실적인 예를 들어 본다면

한국인을 위한 URN을 만들기 위하여 한국-시민 이라고 선언할 수 있다. NSS 로는 유일한 번호, 주민등록 번호를 표현하도록 한다면 000000-0000000 이 될 것이다.

    urn:한국-시민:000000-0000000

지금까지의 내용을 종합해 보면, Namespace를 지정할 때 URI 로 지정한다. URI로는 현재 널리 사용하는 웹주소, URL 방식과 URN 방식이 포함 되어 있다. 일반적으로 URL을 많이 사용하나 URN도 널리 사용 될 것이다. URL에서는 도메인 주소와 거기에 위치한 물리적인 경로가 자원을 찾기 위한 중요한 정보가 되지만, URN은 자원에 부여된 고유한 이름으로 그 자원의 위치와는 무관하게 부여된 이름이다.

이를 구체적으로 예를 들면 , 인천 광역시 남구 용현동에 인하대학교가 있지만, 인하대학교는 새로운 부지로 이사를 갈 수도 있을 것이다. 인하대학교가 어디에 있는지는 URL(주소)로 표현 할 수 있지만, 인하대학교가 다른 곳으로 가더라도 URN을 가지고 그 리소스(인하대학교)을 식별할 수 있다. 이사를 가고 나서 ‘인천광역시 남구 용현동의 인하대학교’ 라는 기존의 주소를 가지고는 인하대학교를 찾을 수 없다. 하지만 인하대학교란 고유한 이름은 변함이 없을 것이다

http://brown.ezphp.net/39 에서 참조

HTML 밖에 모르는 웹 브라우저 ?

웹 브라우저는 HTML밖에 모릅니다. HTML이 브라우저가 쓰는 언어라는 것이지요. (자바스크립트와 같은 약간의 외국어도 합니다.^^;;) 그래서 우리가 홈페이지를 만들려면 모든 문서를 HTML로 작성해야만 합니다.

HTML을 울려 버린 CGI의 등장

인터넷 초창기에는 대부분의 홈페이지가 모두 HTML(SGML)로 만들어져 있었습니다. (선택의 여지가 없었죠)
HTML로 홈페이지를 만들어 보신 분은 아시겠지만 HTML은 일방향적이고 수정하기 전에는 절대 변하지 않는 특성을 가지고 있습니다. 이러한 단점 때문에 사람들은 HTML 말고 다른 무언가가 필요함을 느꼈습니다. 그래서 생겨난 것이 바로 CGI (Common Gateway Interface)입니다.

CGI의 구조

CGI는 위와 같은 구조를 가지는데.. ( HTML은 1과 4의 과정만 있음 ) 보시는 바와 같이 HTML 보다 한단계 더 처리를 함으로써 계산과 처리 기능이 추가되었습니다.  이로 인해 우리는 정적인 웹 페이지에서 변화가 자유롭고 방문자와 홈페이지간에
서로 상호작용이 가능한 웹 페이지를 만들 수 있게 된 것입니다. 그러나 여기서 주의해야 할 점은 3번에서 보듯이 CGI로 처리된 값은 HTML로 전송됩니다. 웹 브라우저가 HTML밖에 모르니 HTML로 결과를 보여줘야 하는 것입니다. 그러니 PHP를 하려면 당연히 HTML을 알고 있어야겠죠?

그러면 CGI와 PHP는 어떤 관계인가?

PHP는 약간 다르긴 하지만 일종의 CGI라고 볼 수 있습니다. 그래서 PHP도 저 위의 그림과 비슷한 구조를 가집니다.

참고. (중급)
CGI는 일반적으로 웹서버로 요청이 들어오면 CGI 프로그램을 실행하여 하나의 프로세스를 생성하고 그 처리 결과를 웹서버로 전송한 후 프로세스가 종료되는 형식입니다. 100개의 요청이 들어오면 CGI 프로세스가 100개가 생성이 됩니다.

PHP는 CGI와 달리 아파치 웹서버에 모듈로 장착되어 있습니다. 따라서 매회 실행시마다 프로세스가 생성되는 CGI와 달리 하나의 프로세스에 여러개의 쓰레드를 생성하여 처리가 가능합니다.

프로세스, 쓰레드?? 뭐가다르냐구요? 프로세스는 각각 별도로 시스템 자원을 소비합니다. 1개의 프로세스가 메모리 1메가바이트를 소비한다면 100개의 경우 100메가 바이트의 메모리를 소비하게 됩니다. 그러나 쓰레드는 쓰레드간에 시스템자원의 공유가 가능하므로 100개라고해서 100메가 바이트를 소비하는 것이 아니라 그보다 훨씬 적은양의 메모리를 소비하게 됩니다.
그래서 프로세스방식인 CGI 보다 쓰레드방식인 PHP가 성능이 우수합니다.

http://brown.ezphp.net/39 에서 참조

HTML 밖에 모르는 웹 브라우저 ?

웹 브라우저는 HTML밖에 모릅니다. HTML이 브라우저가 쓰는 언어라는 것이지요. (자바스크립트와 같은 약간의 외국어도 합니다.^^;;) 그래서 우리가 홈페이지를 만들려면 모든 문서를 HTML로 작성해야만 합니다.

HTML을 울려 버린 CGI의 등장

인터넷 초창기에는 대부분의 홈페이지가 모두 HTML(SGML)로 만들어져 있었습니다. (선택의 여지가 없었죠)
HTML로 홈페이지를 만들어 보신 분은 아시겠지만 HTML은 일방향적이고 수정하기 전에는 절대 변하지 않는 특성을 가지고 있습니다. 이러한 단점 때문에 사람들은 HTML 말고 다른 무언가가 필요함을 느꼈습니다. 그래서 생겨난 것이 바로 CGI (Common Gateway Interface)입니다.

CGI의 구조

CGI는 위와 같은 구조를 가지는데.. ( HTML은 1과 4의 과정만 있음 ) 보시는 바와 같이 HTML 보다 한단계 더 처리를 함으로써 계산과 처리 기능이 추가되었습니다.  이로 인해 우리는 정적인 웹 페이지에서 변화가 자유롭고 방문자와 홈페이지간에
서로 상호작용이 가능한 웹 페이지를 만들 수 있게 된 것입니다. 그러나 여기서 주의해야 할 점은 3번에서 보듯이 CGI로 처리된 값은 HTML로 전송됩니다. 웹 브라우저가 HTML밖에 모르니 HTML로 결과를 보여줘야 하는 것입니다. 그러니 PHP를 하려면 당연히 HTML을 알고 있어야겠죠?

그러면 CGI와 PHP는 어떤 관계인가?

PHP는 약간 다르긴 하지만 일종의 CGI라고 볼 수 있습니다. 그래서 PHP도 저 위의 그림과 비슷한 구조를 가집니다.

참고. (중급)
CGI는 일반적으로 웹서버로 요청이 들어오면 CGI 프로그램을 실행하여 하나의 프로세스를 생성하고 그 처리 결과를 웹서버로 전송한 후 프로세스가 종료되는 형식입니다. 100개의 요청이 들어오면 CGI 프로세스가 100개가 생성이 됩니다.

PHP는 CGI와 달리 아파치 웹서버에 모듈로 장착되어 있습니다. 따라서 매회 실행시마다 프로세스가 생성되는 CGI와 달리 하나의 프로세스에 여러개의 쓰레드를 생성하여 처리가 가능합니다.

프로세스, 쓰레드?? 뭐가다르냐구요? 프로세스는 각각 별도로 시스템 자원을 소비합니다. 1개의 프로세스가 메모리 1메가바이트를 소비한다면 100개의 경우 100메가 바이트의 메모리를 소비하게 됩니다. 그러나 쓰레드는 쓰레드간에 시스템자원의 공유가 가능하므로 100개라고해서 100메가 바이트를 소비하는 것이 아니라 그보다 훨씬 적은양의 메모리를 소비하게 됩니다.
그래서 프로세스방식인 CGI 보다 쓰레드방식인 PHP가 성능이 우수합니다.