테크커런트

🔷 REST API란?

REST API는 REpresentational State Transfer의 약자로,
HTTP 프로토콜을 기반으로 자원의 상태(Representation) 를 주고받는 API 설계 방식을 말합니다.

쉽게 말해, 클라이언트가 서버의 자원에 접근할 수 있도록 설계된 일종의 웹 통신 규칙입니다.

🔷 REST(Representational State Transfer)의 기본 개념

REST는 2000년에 로이 필딩(Roy Fielding)의 논문에서 처음 소개되었습니다.
REST는 다음과 같은 철학과 원칙에 기반합니다:

🔷 RESTful이란?

REST의 아키텍처 스타일을 충실히 지킨 API를 "RESTful API"라고 부릅니다.
즉, REST 원칙에 따라 잘 설계된 API입니다.

🔷 RESTful API의 설계 규칙

RESTful API를 설계할 때 지켜야 할 주요 규칙은 다음과 같습니다:

1. URI는 명사로 구성 (자원을 나타냄)
   • ❌ GET /getUser → ✅ GET /users/1
2. HTTP 메서드로 행위를 표현
   • GET /users → 사용자 목록 조회
   • POST /users → 사용자 생성
   • PUT /users/1 → 사용자 정보 수정
   • DELETE /users/1 → 사용자 삭제
3. 자원 간 계층 표현
   • GET /users/1/posts → 사용자 1의 게시글 목록
4. 상태 코드를 일관되게 반환
   • 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error 등
5. 무상태성(Stateless)
   • 클라이언트 요청 간에 서버는 상태 정보를 저장하지 않음

🔷 RESTful의 장점

• URL이 직관적이고 일관성 있음
• HTTP 기반으로 범용성 좋음
• 다양한 언어와 플랫폼에서 쉽게 사용 가능
• 서버와 클라이언트의 역할이 명확히 구분됨

🔷 RESTful 설계 예시

GET /products           → 상품 목록 조회  
GET /products/10        → 상품 상세 조회  
POST /products          → 상품 등록  
PUT /products/10        → 상품 수정  
DELETE /products/10     → 상품 삭제

✅ 마무리

REST API와 RESTful은 웹 서비스 설계에서 가장 많이 쓰이는 표준입니다.
API를 설계할 때 RESTful 원칙을 따르면 유지보수와 확장성이 훨씬 좋아집니다.

웹 개발에서 클라이언트와 서버 간 통신은 대부분 HTTP 메서드를 통해 이루어집니다.
특히 GET, POST, PUT, PATCH, DELETE는 REST API 설계의 핵심이라고도 할 수 있죠.

이 글에서는 각 메서드의 역할, 차이점, 사용 시 주의사항을 모두 정리해드립니다.

✅ GET

• 목적: 데이터 조회
• 특징:
  • URL 쿼리 파라미터 사용 (/users?name=kim)
  • 데이터 변경 없음
  • 캐시 가능, 브라우저 주소창에서 사용 가능
• 사용 예시: 게시글 목록 조회, 유저 정보 조회 등

✅ POST

• 목적: 데이터 생성 (Create)
• 특징:
  • Body에 JSON, form 데이터 전송
  • 서버 상태를 변경함
  • 재요청 시 중복 생성 주의
• 사용 예시: 회원가입, 글 작성, 댓글 등록

✅ PUT

• 목적: 리소스 전체 수정 (Update All)
• 특징:
  • 존재하지 않는 리소스는 새로 생성할 수도 있음
  • 전송 시 전체 필드 필요
• 사용 예시: 게시글 전체 수정

✅ PATCH

• 목적: 리소스 일부 수정 (Update Partial)
• 특징:
  • 변경되는 필드만 Body에 포함
  • 서버 상태를 부분적으로 변경
• 사용 예시: 유저 닉네임만 변경, 게시글 제목만 수정

✅ DELETE

• 목적: 리소스 삭제
• 특징:
  • 지정된 리소스를 제거
  • 요청 본문은 일반적으로 사용하지 않음
• 사용 예시: 게시글 삭제, 회원 탈퇴

🧠 전체 요약 비교표

웹사이트 주소 앞에 붙는 http://와 https://의 차이, 알고 계신가요?
둘 다 인터넷 통신 규약이지만, 보안 측면에서 큰 차이가 있습니다.

🔍 HTTP란?

• HTTP는 HyperText Transfer Protocol의 약자입니다.
• 인터넷에서 데이터를 주고받는 기본적인 프로토콜입니다.
• 하지만 암호화되지 않기 때문에 보안에 취약합니다.
• 예: http://example.com

🔒 HTTPS란?

• HTTPS는 HTTP + SSL(Secure Socket Layer) 혹은 TLS(Transport Layer Security)입니다.
• 모든 데이터를 암호화해서 주고받기 때문에 도청, 변조, 스니핑 방지에 탁월합니다.
• 예: https://example.com

✅ HTTP vs HTTPS 차이점 정리

🛡 HTTPS의 보안 원리 간단 설명

1. 클라이언트가 서버에게 접속 요청
2. 서버가 공개키 포함된 인증서 전송
3. 클라이언트가 공개키로 세션키 암호화 후 전송
4. 서버가 비공개키로 복호화해 세션키 획득
5. 이후부터는 세션키 기반 대칭키 암호화 통신

즉, 누구도 중간에서 내용을 훔쳐볼 수 없도록 안전한 터널을 만드는 것이 HTTPS입니다.

📌 결론

• HTTP는 보안이 없다.
• HTTPS는 정보를 암호화하여 안전하게 만든다.
• 웹사이트를 운영하거나 이용하는 사람 모두 HTTPS를 사용하는 것이 현대 웹의 기본 상식입니다.

🔷 Forward 방식이란?

Web Container 내부에서 요청을 다음 페이지로 전달하는 방식

• 브라우저는 이동했음을 인지하지 못함
• URL은 바뀌지 않음
• Request와 Response 객체를 공유
• 서버 내부에서 페이지 이동만 발생
• 대표 사용 예: 글 목록, 검색 결과 등 조회용 요청

📌 예시 상황

게시글 작성 완료 후 forward로 응답 페이지를 호출했을 때, 새로고침 시 동일 게시물이 여러 번 등록될 수 있음.
➡️ 왜냐하면 이전 요청 정보가 그대로 유지되기 때문!

🔷 Redirect 방식이란?

서버가 브라우저에게 다른 URL로 이동하라고 지시하는 방식

• 브라우저가 새로운 URL로 이동
• Request/Response 객체는 새로 생성
• URL이 변경됨
• 다른 서버나 컨텍스트로도 이동 가능
• 대표 사용 예: 회원가입, 게시글 등록 등 데이터 변경 요청

📌 예시 상황

게시글 등록 후 redirect를 사용하면, 새로고침해도 중복 등록이 발생하지 않음.
➡️ 왜냐하면 이전 요청 정보가 사라지기 때문!

🔷 Forward vs Redirect 비교 정리

🔷 Spring에서 Redirect 사용 예시

@Controller
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @GetMapping("/signup")
    public String joinForm() {
        return "users/createMember";
    }

    @PostMapping("/signup")
    public String joinForm(@ModelAttribute UserDto.Request userDto) {
        userService.saveUser(userDto);
        return "redirect:/"; // 리다이렉트 처리
    }
}

✅ 마무리

• 단순 조회는 Forward
• DB에 변화를 주는 요청은 Redirect

이 원칙만 기억하면 안정적인 웹 흐름을 구성할 수 있습니다!

📋 본문

오늘은 많은 백엔드/프론트엔드 개발자분들이 헷갈려하는 개념, Stateful과 Stateless의 차이점에 대해 설명드리려 합니다.
서버 아키텍처를 설계할 때 정말 자주 나오는 주제이니, 끝까지 읽어보시면 많은 도움이 되실 거예요!

✅ 1. 정의부터 확실하게!

✅ 2. 장단점 비교

🔹 Stateful

• 장점:
  • 로그인 상태 유지 등 기능 구현이 쉬움
  • MMORPG 같은 실시간 상호작용 서비스에 유리
• 단점:
  • 서버에 리소스 부담
  • 서버 간 세션 공유 어려움 → Scale-out 불리

🔹 Stateless

• 장점:
  • 서버 확장, 로드밸런싱, 캐시 활용 용이
  • REST API, 클라우드 환경에 적합
• 단점:
  • 매 요청 시 상태 정보 포함 → 네트워크 자원 사용 ↑
  • 클라이언트 측 부담 ↑

✅ 3. 서비스 예시로 이해하기

✅ 4. 기술적 이슈 요약

✅ 5. 마무리 요약

• Stateful: 기능 구현은 쉽지만 서버에 부담, 확장성 떨어짐
• Stateless: 구현 복잡하지만 성능, 확장성, 클라우드에 유리
• 선택 기준: 서비스의 실시간성/확장성/안정성에 따라 결정!

📖 본문

1. URL 입력 후 서버로 요청이 가는 과정

브라우저 주소창에 URL을 입력하면, 사실 단순히 “주소”만 보낸 게 아니라 서버에 HTTP Method라는 방식으로 요청을 보낸 것입니다.
HTTP Method는 여러 종류가 있지만, 가장 기본이자 많이 쓰이는 건 GET과 POST입니다.

2. GET 방식 — "책 빌려오는 방법"

📌 개념
필요한 정보를 가져오기 위한 요청 방식입니다.
마치 도서관에서 책을 빌려오는 것과 비슷하죠.

📝 특징

• URL에 데이터가 포함됩니다.

https://example.com/login?id=abcd&pw=kor

• → ? 뒤의 id와 pw가 서버로 전달됩니다.
• 데이터가 Header에 포함되어 전송됩니다.
• URL에 데이터가 노출 → 보안에 취약
• 캐싱 가능 (속도 향상, 즐겨찾기 가능)
• 데이터 전송 길이 제한 존재 (브라우저 제한)
• 바디(Body)는 보통 비어 있음

⚠️ 주의
아이디나 비밀번호 같이 민감한 정보는 절대 GET으로 보내면 안 됩니다.

3. POST 방식 — "편지 봉투 전달하기"

📌 개념
데이터를 서버로 제출하여 추가, 수정하는 방식입니다.

📝 특징

• 데이터는 Body에 포함되어 전송 → URL에 안 보임
• 기본적으로 보안이 GET보다 나음 (하지만 암호화 필요)
• 캐싱 불가
• 길이 제한 없음 (하지만 Time Out 존재)
• Content-Type 헤더로 데이터 형식 명시 필요
• 쿼리스트링 뿐 아니라 폼 데이터, 파일 전송 가능

💡 예시
로그인 폼, 회원가입, 게시글 작성 같은 데이터 입력 기능

4. 캐싱(Caching)이란?

한 번 불러온 데이터를 임시 저장해 두었다가, 다시 요청할 때 더 빠르게 가져오는 기술입니다.
예: 이미지, CSS, JS 파일을 캐싱하면 페이지 로딩 속도가 빨라집니다.

📌 정리 표

인터넷 주소에 대해 공부하다 보면 꼭 마주치는 개념이 있죠. 바로 URI와 URL입니다. 두 개념은 비슷하면서도 엄연히 다릅니다. 이번 글에서는 이 둘의 차이를 명확하게 정리해드립니다.

🔍 URI란?

• URI (Uniform Resource Identifier) 는 말 그대로 ‘통합 자원 식별자’입니다.
• 인터넷상의 특정 리소스(자원)를 식별할 수 있는 문자열을 뜻합니다.
• 예) https://www.example.com/news/123 → 이 전체가 URI

🌐 URL이란?

• URL (Uniform Resource Locator) 은 우리가 흔히 말하는 웹 주소입니다.
• URL은 리소스의 ‘위치’를 알려주는 방식입니다.
• 즉, URI의 서브셋(하위 개념)입니다.

✅ URL과 URI의 차이 정리

✨ 쉽게 말하면?

• 모든 URL은 URI입니다.
• 하지만 모든 URI가 URL은 아닙니다.
• URI = 식별, URL = 위치 라고 기억하세요!

📌 마무리

웹 개발, 백엔드, API 작업 시 이 개념을 잘 알고 있으면 요청 경로 설계 시 큰 도움이 됩니다.
이제 URI와 URL 구분, 더 이상 헷갈리지 않겠죠?

✍️ 서론 개요 (도입부)

웹 시스템을 처음 배우는 사람부터 실무자까지 혼동하기 쉬운 개념이 바로 웹 서버(Web Server) 와 **WAS(Web Application Server)**입니다.
두 용어는 유사하게 들리지만, 역할과 목적은 분명히 다릅니다.

이 글에서는:

• 웹 서버의 정의와 역할
• WAS의 구조 및 동작 과정
• 웹 서비스 아키텍처 흐름
• 왜 Web Server와 WAS를 분리해서 써야 하는지

를 실제 흐름도와 함께 명확하게 정리합니다.

📌 핵심 내용 정리

✅ 웹 서버(Web Server)

• HTTP 요청을 받아 HTML, CSS, JS, 이미지 등의 정적 콘텐츠를 즉시 제공
• 동적 요청은 WAS로 전달하고 결과를 중계
• 대표 소프트웨어: Apache, Nginx

✅ WAS (Web Application Server)

• Servlet, JSP 등의 동적 콘텐츠를 처리하는 미들웨어
• DB 연동, 비즈니스 로직 처리 등 핵심 로직 담당
• 대표 소프트웨어: Tomcat, WebLogic, JBoss

✅ 웹 서비스 아키텍처 구조

✅ 클라이언트 요청의 실제 처리 흐름

1. 클라이언트가 HTTP 요청을 보냄
2. Web Server가 정적 콘텐츠는 즉시 응답,
   동적 요청은 WAS로 전달
3. WAS는 Servlet 생성 → Thread 실행
4. 요청에 따라 doGet() 또는 doPost() 실행
5. 결과 페이지를 Web Server → 클라이언트로 반환

✅ 왜 Web Server와 WAS를 분리해야 할까?

• WAS가 정적 요청까지 처리하면 자원 낭비
• 비즈니스 로직이 느려지고 전체 서비스 지연 발생
• 정적 콘텐츠는 Web Server가 처리 → 부하 분산 & 속도 개선