HTTP · URI

인터넷에서 데이터를 주고 받기 위한 프로토콜

클라이언트 - 서버 모델을 기반으로 동작하며, 웹 브라우저와 웹 서버 간의 통신에 주로 사용됨

요청과 응답
HTTP는 클라이언트가 서버에서 요청(Request)을 보내고,
서버는 클라이언트에게 응답(Response)을 반환하는 형식으로 동작함
URL (Uniform Resource Locator)
HTTP 요청은 URL을 사용하여 특정 리소스를 식별함
URL은 프로토콜(http, https), 도메인, 포트 번호, 경로, 쿼리 등을 사용하여 구성됨
상태 코드 (Staus Code)
HTTP에서 응답을 상태코드로 나타낼 수 있음
해당 요청의 처리 결과를 코드로 나타냄
→ 200 OK : 성공적인 요청
→ 404 Not Found Error : 리소스를 찾을 수 없음
→ 500 Internal Server Error : 서버 내부 오류
메서드 (Method)
GET : 리소스를 조회
POST : 데이터 전송 및 리소스 생성
PUT : 리소스 수정 및 생성
DELETE : 리소스 삭제
상태정보유지
HTTP 프로토콜 자체는 상태정보(Stateless)임
각각의 요청과 응답이 독립적으로 처리됨
사용자의 상태정보 관리를 위해 세션(Session), 쿠키(Cookie), 토큰(Token) 등과 같은 기술을 활용

웹 상의 자원을 식별하기 위한 고유한 식별자

URI의 두 가지 주요 유형

▶ URI는 URL과 URN을 포함하는 상위 개념!

URL (Uniform Resource Locator)

웹에서 특정 자원의 위치를 지정하는 데 사용

자원이 어디에 있는지를 알려주는 역할

사용자와 개발자 모두에게 의미있는 정보를 전달해야 함

웹 어플리케이션에서 리소스에 접근하기 위한 일관된 방법을 정의하는 과정임

URL 설계는 사용자 경험, 검색 엔진 최적화(SEO), 보안 등 다양한 측면을 고려하자구

경로
경로는 계층적 구조를 가짐
각 단계가 리소스의 계층구조와 일치하도록 만들자구
→ /products/electronics/mobilephone 과 같이
→ URL이 상위 카테고리부터 하위 카테고리까지 포함된 경로는 직관적이고 의미가 명확해야함
명명국룰
동사보다 명사, 복수보다 단수
→ /product/electronic/mobilephone
→ /user/kim
대소문자 일관성
→ URL은 대소문자를 구별하기 때문에
→ 대부분 웹서버도 대소문자를 구별하기 때문에
→ 일관성을 위해 소문자 또는 대문자만 사용하는 것이 권장됨
하이픈(-) 사용
→ 단어 사이에 - 넣어서 가독성을 높임
→ 언더바(_), 스페이스( ) 도 가능
→ 하이픈 권장
→ /product/electronic/mobile-phone
쿼리 문자열
필터링, 정렬, 검색과 같은 추가 매개변수가 필요한 경우 쿼리 문자열(query string)을 활용할 수 있음
→ /product?categort=eletronic&sort=price
RESTful 원칙
리소스를 식별하기 위해 각 리소스마다 고유한 식별자(ID)가 포함되어야 함
→ 메서드 사용, 계층구조 같은것도 RESTfull 원칙 중에 있음

▶ 구성요소

JJoa Develog