[Spring] 기초 Spring 1주차-1

Yuri·2025년 1월 20일

목록 보기

1/21

강의목표

Spring Framework를 사용하여 Web Application 만들기
1주차 목표: 네트워크 기초 강의
- Web Application의 구조와 네트워크 통신
- Web 전반의 이해를 돕기 위한 네트워크 기초지식

IDE

IDE(Integrated Development Environment): 소프트웨어 개발을 위해 통합된 환경, 코드 편집기, 디버거, 컴파일러, 자동 완성, 버전 관리 시스템 등 다양한 개발 도구들을 하나의 애플리케이션에서 제동하는 소프트웨어이다.

IntelliJ: 개발자의 생산성을 높여주도록 코드 제안, 자동완성, 다양한 플러그인 지원

Git

Git이란? 분산 버전 관리 시스템으로, 소스 코드의 변경 내역을 추적하고 여러 개발자들이 협업할 수 있게 해준다.
Branch(분기점)에서 일정 시점의 코드를 Commit(저장)할 수 있다.
원격 저장소와의 동기화 기능을 제공한다.
- push: commit한 코드를 원격 저장소에 저장하는 기능
- pull: 원격 저장소의 코드를 local 환경에 불러오는 기능
- checkout: 현재 바라보고 있는 Branch를 전환
- Merge: 코드의 변경 사항(Commit)을 서로 다른 Branch끼리 합치는 기능

네트워크

초기 컴퓨터 간 네트워크 연결은 물리적인 형태로 이루어졌습니다.
하지만, 만약 컴퓨터와 컴퓨터 사이의 거리가 아주 멀리 있다면? 👉 인터넷

인터넷(Internet)

📚 인터넷(Internet)은 인터넷 프로토콜 스위트(TCP/IP)를 기반으로 하여 전 세계적으로 연결되어있는 컴퓨터 네트워크 통신망을 일컫는 말이다.

→ 유/무선 방식(해저 광케이블, 인공위성)으로 이름에 걸맞은 World Wide Web(WWW)이 구축되었다.

인터넷 프로토콜 IP(Internet Protocol)

📚 인터넷 프로토콜은 인터넷이 통하는 네트워크에서 어떤 정보를 수신하고 송신하는 통신에 대한 규약을 의미한다.
→ 복잡한 인터넷 세상에서 데이터를 안전하게 전달하기 위해서는 최소한의 규칙이 필요하다.

IP 주소

각 기기 간의 통신을 식별할 수 있는 식별값(≒ 전화번호)
👉 인터넷 통신 시에는 지정한 IP 주소에 데이터를 Packet 이라는 단위로 전달합니다.

Packet
- 헤더: 소스 IP(출발지), 대상 IP (도착지)
- 페이로드: 전송할 데이터
- 트레일러: 수신여부를 포함 → 데이터를 주기만 하는 것이 아니라 받고 응답한다.

🚨 IP 방식의 문제점

애플리케이션 구분
- 대상 컴퓨터의 어떤 프로그램에서 사용될 데이터인지 구분할 수 없다.
비연결성
- 수신 대상의 현재 상태에 상관없이 데이터를 전송한다.
비신뢰성
- 패킷이 소실되는 경우가 발생한다.
- 패킷의 손상여부를 송신, 수신측 모두 알 수 없다.
- 패킷의 순서가 뒤죽박죽이 되어 섞여서 들어오는 경우가 발생한다.
  → 패킷이 손실되거나, 오류가 발생하여도 데이터의 재전송을 진행하지 않습니다.

⭐️ 위와 같은 IP 방식의 문제점들을 해결해주는 것이 바로 TCP 프로토콜이다.

TCP(Transmission Control Protocol)

서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜
🤨 TCP는 어떻게 데이터를 신뢰성 있게 전달할까요?

3 Way HandShake

용어 설명

SYN(Synchronize)
- 클라이언트가 서버에게 연결을 요청하는 첫 번째 단계
- 클라이언트는 서버에게 "연결을 시작하고 싶다"는 의사를 나타내기 위해 SYN 플래그가 설정된 패킷을 전송한다.
- 패킷에는 시퀀스 번호도 포함되어있고, 데이터 전송 순서를 관리할 준비를 한다.
ACK(Acknowledge)
- 서버가 클라이언트의 SYN 패킷을 받고, 이를 확인했다는 신호를 보내는 단계이다.
- 서버는 클라이언트의 SYN 요청을 수락하며, 자신도 연결을 시작하고 싶다는 뜻을 담아 SYN 플래그와 함께 ACK 플래그가 설정된 패킷을 클라이언트에게 전송한다.
- 이때, 서버는 클라이언트의 시퀀스 번호에 + 1 값을 ACK로 응답한다.

SYN 접속 요청
ACK 요청 수락 → ACK가 없다면 연결 실패
ACK → ACK 함께 데이터 전송 가능
- 데이터 전송 여부 (ACK 반환)
- 패킷 순서 → 패킷이 나뉘어져 올지라도 순서를 보장한다.

TCP는 신뢰성이 있지만, 연결하는 과정, 데이터 전송에 시간이 많이 소요된다.

UDP(User Datagram Protocol)

비연결형, 신뢰성이 없는 전송 프로토콜이다.
실시간 통신이나 스트리밍 애플리케이션에서는 빠른 전송이 중요했기 때문에 UDP는 이러한 요구를 충족하기 위해 개발되었다.
👉 실시간 스트리밍 서비스, 온라인 게임, 인터넷 전화
특징: 실시간성 보장 중요

IP 방식과 거의 비슷하다.
추가적인 기능이 거의 없다.
IP와 차이점으로 PORT가 존재한다.
데이터 무결성 검사 → 체크섬(Checksum)을 포함하고 있다.

PORT

📚 같은 IP 내에서 프로세스 구분을 하기 위해서 사용한다.

TCP/IP Packet 구조
- 소스 PORT, 대상 PORT를 포함한다.
자주 사용되는 PORT

0 ~ 65535 할당 가능
이미 사용되고 있는 포트 (0 ~ 1023)
- HTTP - 80(TCP)
- HTTPS - 443(TCP)

Web 기초

DNS(Domain Name System)

도메인 이름과 IP 주소를 서로 변환하는 역할을 수행한다. 즉, 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환한다.

컴퓨터 간 통신을 위해선 IP 주소가 필요하다.
IP는 변경되는 주소이다.

DNS 동작 순서

원하는 이름의 도메인을 구매 후, DNS 서버에 등록한다.
도메인 명을 입력하면 DNS 서버는 IP 주소를 반환한다.

URI(Uniform Resource Identifier)

인터넷 자원(Resource)을 나타내는 고유 식별자(Identifier)를 뜻한다.

Uniform: 자원(Resource)을 식별하는 통일된 방식을 의미
Resource: 자원(페이지, 텍스트, 이미지, 동영상, 파일 등)을 의미
Identifier: 식별자를 의미
URL(Uniform Resource Locator)
- 자원(Resource)의 위치를 의미한다. ex) 사서가 있는 곳은 도서관
- 일반적으로 도메인주소로 알려져있다.
- 프로토콜을 포함한다.(https://test.com)
자원의 위치를 변경하면 기존 URL을 사용할 수 없다.
👇 이러한 한계를 극복하기 위해서 URN이 등장
URN(Uniform Resource Name)
- 자원(Resource)의 이름(Name)을 의미한다. ex) 사서
- 리소스의 위치가 변경되어도 이름으로 리소스를 찾기 때문에 잘 동작한다.
- 프로토콜을 포함하지 않는다.

URL(Uniform Resource Locator)

URL 구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

scheme
- 주로 프로토콜을 사용한다. 웹에서는 http, https, ftp를 주로 사용한다.
- 참고: https는 http에 보안(Secure)를 추가한 것
user[:password]
- 사용자 정보
- URL은 보안에 취약하여 사용하지 않는다.
host[:port]
- 호스트명: 도메인 명 또는 IP 주소를 직접 사용한다.
- http: 80, https: 443
- 포트는 일반적으로 생략한다.
[/path]
- 리소스의 경로
- 계층 구조로 구성되어있다.
[?query]
- key=value 형태로 구성된다.
- Query Parameter, Query String 이라고도 한다.
- ?로 시작되고 &으로 구분된다.
  ?key1=value1&key2=value2
[#fragment]
- html 내부 북마크 등에 사용한다.
  → 특정 위치(fragment)로 이동할 수 있음

용어 모음집

프로그래밍 명명규칙(Casing)

snake_case
- DB Table, Column에 사용
camelCase
- Java 변수, 함수, 메서드 명
PascalCase
- 클래스 명
kebab-case
- 문자와 문자 사이를 - 로 이어준다.

▶︎ Java의 명명법

종류	설명	예시
project 프로젝트, 레퍼지토리	대/소문자 구분없이 시작	MyProject
package 패키지	소문자 시작	com.example.blog
class 클래스	대문자 시작, 명사 사용, PascalCase	class Person; class Car;
interface 인터페이스	대문자 시작, 형용사 사용, PascalCase	interface Runnable;
method 메서드	소문자 시작, 동사 사용, camelCase	add(); move(); isEmpty();
variable 변수	소문자 시작, camelCase	int number; String inputNumber;
constant 상수	대문자 시작, 문자 사이 `_` 로 구분	static final int MAX_COUNT = 999;

JSON

클라이언트와 서버가 통신할 때 사용하는 데이터 양식이다. 클라이언트와 서버가 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있도록 만들어준다.

💡 XML은 헤더와 태그 등의 여러 요소로 가독성이 떨어지고, 불필요한 용량을 잡아먹는다는 단점을 항상 지적받았다. 이에 대응해 간결하고 통일된 양식으로 각광을 받고 있는 것이 JSON 이다.

JSON은 사람, 기계 모두 이해하기 쉬우며 용량이 작다.
XML을 대체해서 데이터 전송 등에 많이 사용한다.
JavaScript Object Notation
JSON 구조

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

MSA(MicroService Architecture)

아주 작은 단위로 서비스를 잘게 나누어 운영하는 아키텍처

구성된 Application 마다 어떠한 언어를 사용하는지에 상관없이 서로 통신을 할 수 있는데 이것이 가능한 이유는 JSON 형태로 데이터 통신을 하기 때문이다.

Scale Up, Scale Out

서버의 성능 향상을 위한 두 가지 방법

Scale Up
- 수직적 확장
- 단일 서버의 하드웨어의 사용을 높인다. (CPU, Memory 등의 스펙을 높인다.)
- 요청에 대한 처리를 더욱 빠르게 할 수 있도록 만든다.
- 비용이 기하급수적으로 증가한다.
Scale Out
- 같은 사양의 서버(인스턴스)를 여러 대 배치한다.
- 동시에 더 많은 사용자 요청을 처리할 수 있도록 만든다.
- 비용이 수직 확장에 비해 적절한 비용 증가가 발생한다.

Stateful, Stateless

클라이언트와 서버간의 통신 상태(state) 유지 여부에 따라 나뉘는 특성

Stateful(상태 유지): 클라이언트의 상태를 유지
→ 클라이언트의 요청을 기억(상태 유지)하여 다음 질문들에 대한 처리가 가능
🤨 문제점: 같은 서버가 유지가 되어야 한다.
(서버는 다양한 이유로 동작하지 않을 수 있다, 요청 트래픽이 몰리게 되면 상태를 유지하는 것에 Resource가 많이 소모된다.)
Stateless(무상태): 클라이언트의 상태를 유지하지 않는다.
클라이언트 측에서 요청할 때 마다 다음 요청에 함께 전달 → 서버는 클라이언트의 요청을 기억하고 있을 필요가 없다.
- 장점
  - 같은 서버를 유지할 필요가 없다.
  - Scale Out 수평 확장성이 높다.
- 단점
  - 클라이언트가 데이터를 추가적으로 전송해야 한다.
Stateless 방식의 한계점
- WebApplication을 만들때 서버의 확장성을 고려하여 최대한 Stateless하게 만들어야 한다.
- 로그인과 같은 상태 유지해야하는 경우 → Cookie, Session, Token 등을 활용하여 이러한 한계를 극복한다.

Connection, Conectionless

클라이언트와 서버 간의 연결(Connection) 유지 여부에 따라 나뉘는 특성이다.

Connection(연결)
- 서버는 클라이언트와 연결을 유지하기 위해서 자원을 소모한다.
- 하지만, 수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 작다.
- 장·단점: 새로운 연결과정을 거치지 않아 응답속도가 빠르다 / 연결을 위한 자원이 낭비된다.
Connectionless(비연결)
- 클라이언트와 서버는 연결을 유지하지 않는다.
- 서버는 최소한의 자원만을 사용한다.
- 장·단점: 서버 자원을 효율적으로 사용할 수 있다. / 요청이 추가적으로 오게되면 연결(3 Way Handshake)을 새로 해야한다. → 요청에 대한 응답 시간이 증가한다. 웹사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다. 👉 캐시, 브라우저 캐싱으로 해결한다.

HTTP 지속연결(Persistent Connections)
- 하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지한다.
- 연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다.
→ 그만큼 속도가 빨라졌다.
```
    
```

HTTP

HTTP(HyperText Transfer Protocol)

Text, Image, File, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송된다. 대부분 HTTP/1.1(TCP)을 사용한다. 현대에는 HTTP/2, HTTP/3(UPD)의 사용량이 급속도로 증가하는 추세이다.

HTTP는 클라이언트 to 서버, 서버 to 클라이언트, 서버 to 서버 간의 데이터 통신에 사용된다.

HTTP 동작 순서
- 클라이언트는 Request(요청)을 보내고, 응답을 기다린다.
- 서버는 요청에 대한 처리를 수행 후 결과를 Response(응답)한다.
특징
인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다. 서버에서 다수의 클라이언트와 상태나 연결을 계속 유지해야 한다면 이에 따른 많은 서버의 리소스가 필요하다.

▶︎ 클라이언트와 서버 구조
▶︎ 무상태(Stateless): 서버는 클라이언트의 상태를 보존하지 않는다.
▶︎ 비연결(Connectionless): 연결을 유지하지 않음

HTTP Message 구조

HTTP Message는 요청 메세지, 응답 메세지 두 가지 종류가 있고 구조가 각각 다르다.

 HTTP-message   = start-line
                  *( header-field CRLF )
                  CRLF
                  [ message-body ]

요청

Start-line
- HTTP Method
  - GET
- 요청의 의도를 가진 GET, POST, PUT, PATCH, DELETE 등이 있다.
  - Create - POST
  - Read - GET
  - Update - PUT(전체), PATCH(일부)
  - Delete - DELETE
  - Request Target
- path
  - /event
  - HTTP Request가 전송되는 대상, 절대경로
  - Query String(=Query Parameter)
- HTTP Version
  - 1.1
Header
- Host: spartacodingclub.kr
- field-name: OWS field-value (OWS: 띄어쓰기 허용)
- field-name 은 대소문자 구분을 하지 않는다.
- 요청의 추가 정보들을 가지고 있다.
  ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
Empty Line
- 공백 한 줄
- 필수값
Message Body
- 실제 전송하는 데이터가 담겨 있는 부분
- 요청 시 GET의 경우 지원되지 않는 경우가 많다

응답

Start-line
- HTTP Version
- Status Code: 요청이 성공했는지, 실패했는지 나타내는 코드
- Status Text
Header
- Response에서만 사용되는 Header 값들이 따로 존재한다. (Content-Type, Content-length ...)
Empty Line
- 공백 한 줄
- 필수값
Message Body
- 실제 전송하는 데이터가 담겨 있는 부분
- 만약 전송할 데이터가 없다면 Body가 공백으로 존재한다.

HTTP Method

POST

Create 리소스 생성

주로 HTML FORM(회원가입, 게시글 작성 등)에 사용된다.
요청 데이터를 처리하는 방식에 정해진 것은 없다.
1. 요청 데이터 처리(로그인 등)에 사용한다.
1. 조회 시 JSON 요청 데이터가 필요한 경우에도 사용될 수 있다.
2. Message Body를 통해 요청 데이터를 전달한다.

GET

create 리소스 조회

Query String을 미포함하는 경우
Query String 포함하는 경우
- 서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String을 사용한다.

PUT

Update 리소스 덮어쓰기

POST와 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정한다.

기존 리소스가 존재하는 경우: 식별 리소스 전체를 대체한다.
기존 리소스가 존재하고 일부만 변경하는 경우 → ❌(기존 리소스의 전체가 수정되어 데이터 유실 발생)
기존 리소스가 없는 경우: 리소스가 없으면 생성된다.

PATCH

Update 리소스 부분 수정
기존 Resource 에서 전달된 내용이 부분 수정됨

DELETE

Delete 리소스 삭제

기타 Method

HEAD
OPTIONS
CONNECT
TRACE

HTTP Method 속성

안정성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable) 속성을 가지고 있다.

Request method	RFC	Request has payload body	Response has payload body	Safe	Idempotent	Cacheable
GET	RFC 9110	Optional	Yes	Yes	Yes	Yes
POST	RFC 9110	Yes	Yes	No	No	Yes
PUT	RFC 9110	Yes	Yes	No	Yes	No
DELETE	RFC 9110	Optional	Yes	No	Yes	No
PATCH	RFC 5789	Yes	Yes	No	No	No

Optional은 Java의 Optional과 같이 있을 수 있다라는 말과 같다.

1. 안정성(Safe)

데이터를 변환하는 것은 불안정하다
- GET 메소드는 안전하다.
- POST, DELETE, PUT, PATCH는 안전하지 않다.

2. 멱등성(Idempotent)

한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
- GET → 같은 결과가 계속 조회된다.
- PUT → 수정해서 대체된 후의 결과는 계속 같다.
- DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
- POST → 멱등성을 보장하지 않는다.
  ex) 계좌 송금을 두번 한다면, 게시판 글쓰기, 회원가입
- 요청이 실패한 경우 재시도 하기위해 필요하다.
  → 복구 매커니즘에 사용한다.
- 재요청 중간에 리소스가 변경되는 것은 멱등성으로 고려하지 않는다.

3. 캐시가능성(Cacheable)

재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
- GET, HEAD, POST 메소드는 캐시가 가능하다.
- GET, HEAD 정도만 캐시로 사용한다.

💡 캐시(Cache)란?
클라이언트가 서버에 한번 요청했던 데이터에 대해서 매번 요청할 때 마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다.

HTTP 상태 코드

1xx(정보)
2xx(성공)
- 200 OK
3xx(리다이렉션): 요청을 완료하려면 추가 행동이 필요한 상태
- 300은 사용하지 않는다
- 영구 리다이렉션: URL 영구 변경 (301[308] 응답: 새 URL 전달)
- 일시 리다이렉션: URL 일시 변경, PRG(Post, Redirect, Get) 패턴 → PRG 패턴을 적용하지 않으면 새로고침 시 POST 요청이 중복으로 처리, 적용하면 새로고침 시 GET
- 기타 리다이렉션: 캐시를 활용할 것인지 여부
4xx(클라이언트 에러)
- 클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패
- 400(Bad Request), 401(Unauthorized), 403(Forbidden), 404(Not Found)
5xx(서버 에러)
- 서버 오류, 재시도하면 성공할 수 있다.
- 500(Internal Server Error), 503(Service Unavailable)

👉 응답 코드를 상황에 맞게 잘 작성 해야 한다.

HTTP API 설계

URI
- 리소스 식별자
HTTP Message
- HTTP 통신에서 주고받는 데이터
HTTP Method
- 처리할 행위

HTTP API 설계 방법

HTTP API 설계시 항상 리소스 식별을 기준으로 삼아야한다.
예시에서 리소스는 게시글(board)이다.
URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다. board → boards
URL에 동사를 사용하지 않는다.
HTTP Method의 역할을 URL에 포함하지 않는다.

HTTP API 설계

게시글 생성
- POST
- /boards
- 성공시 상태코드 2xx
- 실패시 4xx(클라이언트 에러) OR 5xx(서버 에러)
게시글 1개 조회
- GET
- /boards/{id}
- 성공시 상태코드 2xx
- 실패시 4xx(클라이언트 에러) OR 5xx(서버 에러)
게시글 목록 조회
- GET
- /boards
- 성공시 상태코드 2xx
- 실패시 4xx(클라이언트 에러) OR 5xx(서버 에러)
게시글 수정
- PUT or PATCH
- /boards/{id}
- 성공시 상태코드 2xx
- 실패시 4xx(클라이언트 에러) OR 5xx(서버 에러)
게시글 삭제
- DELETE
- /boards/{id}
- 성공시 상태코드 2xx
- 실패시 4xx(클라이언트 에러) OR 5xx(서버 에러)

✏️ Restful API

HTTP Header

클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 만들어준다.

HTTP 전송에 필요한 모든 부가정보를 표현할 수 있다.
임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함
개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보

HTTP Header 모음집

▶︎ 표현 헤더(Representation)

실제 데이터를 전송할 때 특정 형식으로 변환
리소스에 대한 표현 정보를 나타낸다.
요청, 응답에 모두 사용되는 Header이다.
종류
- Content-Type: 형식
  - text/html; charset=utf-8
  - application/json
- Content-Encoding: 압축 방식
  - gzip
  - identity
- Content-Language: 언어
  - ko
  - en
- Content-Length: 길이
  - 실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더이다.

▶︎ 컨텐츠 협상(Content Negotitation)

클라이언트가 요청시에 선호하는 표현을 요청한다.
우선 순위가 존재한다.
- 0~1 사이의 값이 존재하며 1에 가까울수록 우선순위가 높다.
- Value가 1인 경우 생략이 가능하다.
ex) Accept-language: ko-KR, en-US;q=0.9,en;q=0.8
→ 서버에서 지원 가능하다면 우선순위를 기반으로 응답 데이터를 표현한다.
q가 생략되었다면 선언된 순서대로 우선순위를 가진다.
구체적으로 선언된 것이 우선순위가 높다.
종류
- Accept: 선호 미디어 타입
- Accept-Charset: 선호 문자 인코딩
- Accept-Encoding: 선호 압축 인코딩
- Accept-Language: 선호 언어

▶︎ 일반 정보

단순한 정보들을 나타내는 Header
종류
- ~~From: 클라이언트 이메일 정보~~
- Referer: 현재 요청된 페이지의 이전 웹 페이지 주소
- User-Agent: 클라이언트 애플리케이션 정보
- Server: 요청을 처리하는 ORIGIN 서버의 Software 정보
- Date: HTTP 요청이 발생한 날짜와 시간

▶︎ 특별 정보

Host: 요청한 도메인의 정보
Location: 생성된 리소스 URI, 리다이렉트 주소
Allow: 허용 가능한 HTTP Method
Retry-After: 다음 요청까지 대기 해야하는 시간

▶︎ 인증

Authorization: 클라이언트 인증 정보
WWW-Authenticate: 리소스에 필요한 인증 방법

▶︎ Cookie

HTTP 에서 Stateless 특성을 가지고 있어서 상태를 매번 보내주어야 한다.
Cookie를 사용하여 모든 요청마다 상태를 전달한다.
사용자 세션 관리, 광고 정보 트래킹에 많이 사용된다.
종류
- Set-Cookie: 서버에서 응답시 클라이언트로 Cookie 값 전달
  - 만료기간, 사용될 위치를 설정할 수 있다.
  - 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽 최적화 시켜야 한다.
  - 탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않는다.
- Cookie: 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송한다.
- Secure: 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송한다.
- HttpOnly: http 전송에만 사용한다.
  - 자바스크립트에서 쿠키를 접근하지 못하게 만든다.
- SameSite: 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

▶︎ Cache
캐시가 없다면 같은 요청에 대한 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받는다.
새로 다운로드 받는만큼 속도가 느려지고, 비용이 발생한다.

종류
- Cache-Control: max-age
  - 캐시 유효 시간(초)
- Cache-Control: no-cache
  - 캐시 가능한 데이터지만, 서버에 검증하고 사용해야 한다.
- Cache-Control: no-store
  - 보안에 민감한 데이터, 캐시하지 않는다.
- if-modified-since: 캐시로 저장된 데이터 최종 수정일
- Last-Modified: 데이터가 마지막으로 수정된 시간
- ETag: 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정

Restful API

📚 REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원을 관리. 자원은 고유한 URI로 식별되며, HTTP 메서드(GET, POST, PUT, DELETE 등)을 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어진다.

REST(Representational State Transfer)

자원(Resource)를 이름(Name)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것을 의미한다.
→ URI를 통해 자원(Resource)을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 REST라 칭한다.

🚩 Restful API Best Practice

리소스는 명사를 사용해야 한다.
단수가 아닌 복수 형태를 사용해야 한다.
만약, REST만으로 해결하기 어려운 경우라면 동사를 허용한다.
자원의 계층 관계를 슬래시(/)로 표현한다.
마지막 문자에는 슬래시(/)가 있으면 안된다.
언더바(_)가 아닌 하이픈(-)을 사용해야 한다.
소문자를 사용해야 한다.
URI에 파일 확장자를 포함하면 안된다.
CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.
정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 한다.

▶︎ Maturity Model (성숙도 모델)
REST의 제약 조건에 따라 API를 등급화하는 방법

Level0 / Level1 / Level2 / Level3
RESTful Service의 DB에 저장된 리소스를 확인하고 이러한 데이터를 조작하기 위해서 CRUD와 매칭되는 HTTP Methods를 이용하여 서비스 하는 단계 👉 Level2

GET /users/123     // 특정 사용자 조회

POST /users        // 사용자 생성
{
    "name": "sparta",
    "password": "codingclub"
}

PUT /users/123     // 사용자 정보 수정
{
    "name": "java",
    "password": "spring"
}

DELETE /users/123  // 사용자 삭제

데이터를 가지고 그 다음 작업에서 어떠한 작업을 할 수 있는지 상태 정보를 함께 넘겨준다. 👉 Level3

GET /users/123
{
    "id": 123,
    "name": "sparta",
    "links": {
        "self": "/users/123",
        "update": "/users/123",
        "delete": "/users/123"
    }
}

RESTful API 설계 시 고려해야 할 사항

소비자 입장
HTTP의 장점을 살려서 개발
최소 성숙도 모델 Level2
API 요청에 따라 적절한 HTTP 상태코드 전달
URI에는 사용자 정보 포함 X
데이터는 단수가 아닌 복수형태
모든 리소스는 가능하면 동사가 아닌 명사형태
일괄적인 엔드포인트를 사용

Yuri

안녕하세요 :)

다음 포스트

[Spring] 기초 Spring 1주차-1

Spring

강의목표

IDE

Git

네트워크

인터넷(Internet)

IP 주소

TCP(Transmission Control Protocol)

UDP(User Datagram Protocol)

PORT

Web 기초

DNS(Domain Name System)

URI(Uniform Resource Identifier)

URL(Uniform Resource Locator)

용어 모음집

프로그래밍 명명규칙(Casing)

JSON

MSA(MicroService Architecture)

Scale Up, Scale Out

Stateful, Stateless

Connection, Conectionless

HTTP

HTTP(HyperText Transfer Protocol)

HTTP Message 구조

요청

응답

HTTP Method

POST

GET

PUT

PATCH

DELETE

기타 Method

HTTP Method 속성

1. 안정성(Safe)

2. 멱등성(Idempotent)

3. 캐시가능성(Cacheable)

HTTP 상태 코드

HTTP API 설계

HTTP API 설계 방법

HTTP API 설계

HTTP Header

HTTP Header 모음집

Restful API

REST(Representational State Transfer)

RESTful API 설계 시 고려해야 할 사항

[Spring] 기초 Spring 1주차-2

0개의 댓글