URL과 리소스
URL은 인터넷의 리소스를 가리키는 표준이름이다.
브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킨다.
좀 더 일반화된 부류인 URI의 부분 집합이다.
URI에는 URL과 URN가 속해있다. (주로 URL이 쓰인다.)
URL 주요 요소
1. 스킴(어떻게)
클라이언트가 리소스에 어떻게 접근해야하는지(어떤 프로토콜을 사용해야하는지) 알려준다.
리소스의 종류에 따라 달라진다.
2. 서버의 위치(어디에)
서버 도메인 이름 또는 ip주소
3. 리소스의 경로(무엇을)
서버에 있는 데이터의 폴더 구조 경로
URL문법
일반적으로 9개의 부분으로 나뉜다.
<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>1.스킴
- 클라이언트가 리소스에 어떻게 접근해야하는지(어떤 프로토콜을 사용해야하는지) 알려준다.
- 리소스의 종류에 따라 달라진다.
- 대,소문자 구분없다.
2.사용자이름:비밀번호@
- 몇몇 스킴(대표적으로 FTP)은 리소스에 접근 하기 위해 사용자 이름,비밀번호를 필요로한다.
- 사용자이름 기본값: 'anonymous'
- 비밀번호 기본값: 브라우저마다 가지는 기본값
- '@'로 다른 url과 구분한다.
3.호스트:포트
리소스를 찾기 위해서는 리소스를 호스팅하고 있는 장비와
그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.
- 호스트: 리소스를 가지고 있는 인터넷상의 호스트 장비(컴퓨터)
- 포트: 서버가 열어놓은 네트워크 포트
4.경로
- 리소스가 서버의 어디에 있는지 알려준다.
- 계층적 파일 시스템 경로와 유사한 구조를 가진다.
- '/'를 기준으로 경로조각으로 나뉜다.
- 경로조각은 자체만의 파라미터를 가질 수 있다.
5.파라미터
- 좀 더 구체적인 요청을 위해 추가적인 정보를 보내줄 때 사용한다.
- '이름=값' 쌍으로 앞에 ';'을 붙여 구분한다.
6.질의
- 데이터베이스와 같은 게이트웨이에서 요청받을 이소스 형식의 범위를 좁히기 위해 사용한다.
- 서버는 url에서 쿼리부분을 게이트웨이에 전달한다.
- 포맷 제약사항은 없지만 편의상 많은 게이트웨이가 '&'로 나뉜 '이름=값' 쌍 형태를 원한다.
7.프래그먼트
- HTML같은 리소스는 본래의 수준보다 더 작게 나뉠 수 있다.
- 리소스 안에 있는 특정 부분을 가리키기위해 사용한다. (ex-2번째 문단부터 보여주고 싶을 때)
- 서버는 리소스 전체만 다루기 때문에 클라이언트가 서버에 프래그먼트를 전달하지 않는다.
- 클라이언트에서 받아온 리소스에서 특정 부분을 보여줄 때 사용한다.
안전하지 않은 문자 사용하기
컴퓨터 시스템의 기본 문자 집합은 보통 영어 중심으로 설정되어있고, 많은 컴퓨터 애플리케이션이 US-ASCII문자 집합을 사용해왔다. 그래서 US-ASCII문자 집합을 사용하는것이 어떤 장치나 애플리케이션에도 호환되어 안전하다.
하지만 US-ASCII문자 집합은 만들어진 지 오래되었기 때문에 적은 수의 문자만을 포함하고 있다.
미국외에 전 세계의 언어들에 존재하는 변형된 문자들까지 US-ASCII가 지원하지 않는다.
url설계자는 사람들이 URL에 이진데이터나 일반적으로 안전한 알파벳 외의 문자도 포함하려고 할 때가 있다는 것을 알게되었다. 이런 것들을 지원하기 위해 url설계자들은 이스케이프라는 기능을 추가하여, url에 US-ASCII가 지원하지 않는 문자들이나 이진데이터 같은 안전하지 않은 문자들을 인코딩하여 안전한 문자로 사용할 수 있게 했다.
인코딩 체계
url내에서 안전하지 않은 문자는 %기호로 시작해 ASCII코드로 표현되는 두개의 16진수 숫자로 이루어진 이스케이프 문자로 바꾸어 인코딩해야 한다.
~abc.html -> http://www.yyoooon.com/%7abc.html문자 제한
몇몇 문자는 url내에서 특별한 의미로 예약되어있다.
이런 예약 문자들을 본래의 목적이 아닌 다른 용도로 사용하려면 이스케이프 문자로 작성해서 인코딩해야한다.
encodeURI('')메소드를 사용하면 편리하게 url을 인코딩할 수 있다.
하지만 예약 문자는 인코딩하지 않는다.
URI의 미래와 URN
URL의 한계
URL은 사실 주소이지 실제 이름은 아니다. URL은 특정 시점에 어떤 것이 위치한 곳을 일려준다는 것을 뜻한다.
문제는 리소스가 옮겨지며녀 URL을 더 이상 사용할 수 없고, 그 시점에 기존 URL이 가리키고 있던 객체를 찾을 방법이 없어진다는 것이다.
URN의 등장
이를 해결할 방법은 리소스의 위치와 상관없이 그 리소스를 가리키는 고유한 이름을 사용하는 것이다.
이를 위해 URN이 고안되었다. URN은 리소스 위치가 변경되어도 항상 그 리소스를 가리키는 고유한 이름을 제공한다.
PURL을 사용하면 URL로도 URN을 사용할 수 있다. PURL은 리소스의 실제 URL목록을 관리하고 추적하는 중개 서버이다.
URL에서 URN으로 주소체계를 바꾸는 것은 매우 큰 작업이다. 표준을 재정하고, 여러 HTTP애플리케이션을 수정해야한다. 시간이 많이 걸리기 때문에 URL은 당분간 계속 사용될 것이다.
궁금한 점
책에서 나온 파라미터(;key=value)와 쿼리(?key=value)의 형태와 사용법이 비슷해서 각각 어떤 때에 사용해야하는지 궁금해졌다. 하지만 검색했을 때 저런 형태로 사용하는 파라미터에 대한 정보를 찾지 못했다.
프론트 개발하면서 사용하는 파라미터는 저런 형태가 아니라 products/:productId형태였다.
그래서 주로 사용하는 형태의 파라미터와 쿼리의 사용법에 대해 알아보았다.
Query String VS Path Variable
Path Variable은 특정 인덱스에 대한 조회.
Query String 은 특정 값으로 필터링.
Example)
아이디가 20번인 유저 조회 -> Path Variable 사용 -> GET /user/:userid
이름이 james이고 20살인 유저 조회 -> Query String 사용 -> GET /user?userName=james&?age=20
만약 어떤 resource를 식별하고 싶으면 Path Variable을 사용하고...정렬이나 필터링을 한다면 Query Parameter를 사용하는 것이 가장 이상적 입니다!
출처: https://yusang.tistory.com/70 [YS's develop story:티스토리]
