개발일기🌷

URI (Uniform Resource Identifier)

• 특정 리소스를 식별하는 통합 자원 식별자를 의미
• 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스

→ Uniform : 리소스를 식별하는 통일된 방식

→ Resource : URI로 식별이 가능한 모든 종류의 자원(웹 브라우저 파일 및 그 이외의 리소스 포함)

→ Identifier : 다른 항목과 구분하기 위해 필요한 정보 

• Scheme : 리소스에 접근하는데 사용할 프로토콜. 웹에서는 http 또는 https를 사용
• Host : 접근할 대상(서버)의 호스트명
• Path : 접근할 대상(서버)의 경로에 대한 상세정보 (URN)
  → URN은 리소스의 위치, 프로토콜, 호스트 등과는 상관없이 각 자원에 이름을 부여한 것.
       물리적인 위치와 상관없이 웹 문서 자체를 나타낸다.

URL (Uniform Resource Locator)

• 흔히 웹 주소라고 하며, 네트워크상에서 통합 자원(리소스)의 “위치”를 나타내기 위한 규약.
  즉, 자원 식별자와 위치를 동시에 보여줌
• 특정 웹 페이지의 주소에 접속하기 위해서는 웹 사이트의 주소뿐만 아니라 프로토콜(https, http, sftp, smp 등)을
  함께 알아야 접속이 가능한데, 이들을 모두 나타내는 것이 URL
• URI의 일종
• 프로토콜과 결합한 형태
  → 어떻게 위치를 찾고 도달할 수 있는지 포함해야하므로 프로토콜 + 이름(또는 번호)의 형태여야 한다.

URL 구조

》프로토콜

https, http는 웹브라우저와 웹서버 사이에서 웹문서 및 구성 자원을 정송하기 위한 프로토콜

많은 웹사이트들이 https를 기본 프로토콜로 사용하며 http보다 보안이 강화된 버전

》도메인

URL에서 웹서버의 위치를 지정하는 부분

》포트번호

웹서버에서 자원을 접근하기 위해 사용하는 게이트 번호

》서브디렉토리

해당 페이지가 위치한 파일 시스템의 경로로서 웹 페이지 또는파일을 구성하는 데 사용되는 디렉토리를 나타냄
서브 디렉토리를 통해 페이지가 현재 어느 페이지의 하위로 들어가 있는지 확인 가능

동적  URL, 정적 URL

》동적 URL

 ‘?’이나 ‘&’과 같은 매개변수 값의 조합으로 만들어지는 URL 구조

예) http://example.com/?doc=cart/item.php&it_id=198577

》정적 URL

매개변수가 포함되어 있지 않으며 서브 디렉토리의 구조 및 해당 페이지의 주요 내용을 파악할 수 있는 URL 구조

예) https://www.example.com/product/shirts

프로토콜

• 컴퓨터 내부에서 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙체계
• 기기 간 통신은 교환되는 데이터 형식에 대해 상호합의를 요구하며, 이런 형식을 정의하는 규칙의 집합이 프로토콜

HTTP 프로토콜

• 인터넷 상에서 데이터를 주고받기 위한 서버/클라이언트 모델을 따르는 프로토콜
• 애플리케이션 레벨의 프로토콜로, TCP/IP 위에서 작동
• 어떤 종류의 데이터든 전송할 수 있도록 설계되어있음

HTTP 프로토콜의 작동방식

서버/클라이언트 모델을 따르고, 클라이언트에서 요청(request)을 보내면 서버는 응답(response)한다.

HTTP 메서드 

• HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냄
• 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 메서드 집합간에 서로 공유하기도 함
• HTTP Method : REST(Representational State Transfer)를 지키면서 행위를 전달하는 방법
  → 2000년도에 로이 필딩이 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표
  → 지원(Resource) : URI
       행위(Verb) : HTTP Method
       표현(Representations)
  

HTTP 메서드 종류

1. GET(조회) : 서버로부터 데이터를 취득
2. POST(등록) : 서버에 데이터를 추가, 작성
3. PUT(수정) : 서버의 데이터를 갱신, 작성
4. PATCH : 리소스의 일부분을 수정
5. DELETE(삭제) : 서버의 데이터를 삭제
6. HEAD : 서버의 리소스의 헤더(메타 데이터의 취득)
7. OPTIONS : 리소스가 지원하고 있는 메소드의 취득
8. CONNECT : 프록시 동작의 터널 접속을 변경

 GET

클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용되는 메서드

데이터를 읽거나(Read), 검색(Retrieve)할 때에 사용

URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링 (query string) 이라고 부른다.
URL 끝에 " ? " 를 붙이고 그다음 변수명1=값1&변수명2=값2... 형식으로 이어 붙이면 된다.
예) www.example.com/show?name1=홍길동&name2=김둘리
→ 서버에서는 name1 과 name2 라는 파라미터 명으로 각각 홍길동과 김둘리의 파라미터 값을 전달 받을 수 있다.

POST

리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용되는 메서드

GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송

HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있(GET과 달리 대용량 데이터를 전송할 수 있는 이유)

GET 과 POST

Idempotent (= 멱등법칙, 멱등성)

• 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질
• GET 이 idempotent 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러번 전송하더라도
  동일한 응답이 돌아와야한다는 것을 의미함. 따라서, GET은 주로 조회할때 사용
• 반대로 POST는 Non-Idempotent하기 때문에 서버에 동일한 요청을 여러번 전송해도 응답은 항상 다를 수 있다.
  따라서, POST는 서버의 상태나 데이터를 변경시킬 때 사용.