[#3][다시, 처음부터 #2] HTTP & REST 기본기

1. 개념 설명 (Concept)

• HTTP (HyperText Transfer Protocol)
  웹에서 클라이언트(브라우저, 앱)와 서버가 데이터를 주고받을 때 사용하는 통신 규약.
  예: 크롬 브라우저가 https://naver.com 요청 → 서버가 HTML 응답.
• 요청/응답 구조
  • 요청(Request): URL, HTTP Method(GET/POST 등), Header, Body
  • 응답(Response): 상태 코드(200, 404, 500), Header, Body(JSON 등)
• REST (Representational State Transfer)
  HTTP를 활용해 리소스를 명확히 식별하고(URL), 그 리소스에 대한 행위를 HTTP 메서드로 표현하는 아키텍처 스타일.
  👉 예: /users/1 (리소스), GET(읽기), POST(생성)

---

2. 올바른 용어 (Terminology)

 

영어	한국어	설명
HTTP Method	HTTP 메서드	GET, POST, PUT, DELETE 같은 동작 방식
Request / Response	요청 / 응답	클라이언트가 보내는 것 / 서버가 돌려주는 것
Header	헤더	요청·응답에 추가 정보(meta data) 포함
Body	바디	실제 데이터(JSON, HTML 등)
Status Code	상태 코드	요청 처리 결과 (200 OK, 404 Not Found, 500 Internal Server Error 등)
RESTful	RESTful	REST 원칙을 잘 지킨 API 디자인 방식

---

 

3. 잘못 쓰기 쉬운 표현 + 실제 맥락 (Misuse & Context)

• ❌ “POST는 로그인할 때만 쓰는 거다” → 잘못된 표현
  ✔ POST는 리소스 생성/전송이 기본 의미, 로그인 요청도 단지 “데이터를 보낸다”라서 POST를 쓰는 것.
• ❌ “REST API = JSON API” → 혼동
  ✔ REST는 아키텍처 스타일, JSON은 데이터 포맷. REST API는 JSON뿐 아니라 XML, HTML 등도 응답할 수 있음.
• ❌ “200은 무조건 성공” → 부정확
  ✔ 200 OK도 있고, 201 Created, 204 No Content 등도 있음. 상황에 맞게 써야 함.

 

---

4. 면접 예시 (Interview Q&A)

• Q: “RESTful API란 무엇인가요?”
  A: “REST 아키텍처 스타일을 따르는 API를 의미합니다. 리소스를 URI로 표현하고, HTTP 메서드로 행위를 구분하며, 상태 코드를 통해 결과를 전달하는 것이 핵심입니다.”
• Q: “GET과 POST의 차이를 설명해보세요.”
  A: “GET은 서버에서 데이터를 조회할 때, POST는 새로운 데이터를 생성하거나 서버에 전달할 때 사용합니다. GET은 URL에 파라미터가 포함될 수 있고, POST는 요청 바디를 사용합니다.”

---

5. 오늘 학습 체크 질문 (HTTP & REST)

Q1. HTTP 요청(Request)의 4가지 주요 요소를 쓰시오.

(힌트: URL, …) 

정답:

URL (요청할 리소스 주소) Method (GET, POST, PUT, DELETE 등 동작 방식) Header (요청에 대한 부가 정보: 인증 토큰, Content-Type 등) Body (실제 전송 데이터, 보통 POST/PUT 요청에 포함)

👉 경훈님이 말한 “앞의 두 개가 헤더에 들어가는 거 아닌가?” → 좋은 의문이에요.

URL & Method는 Request Line에 들어가고, Header & Body는 그 뒤에 따로 들어가요.

즉, URL/Method는 Header에 포함되는 게 아니라 **독립적인 첫 줄(Request Line)**이에요.

GET /users/1 HTTP/1.1
Host: example.com
Content-Type: application/json​

 

Q2. HTTP 응답(Response)에서 반드시 포함되는 핵심 요소 2가지는 무엇인가?

정답:

Status Code (상태 코드: 200, 404, 500 등) Body (응답 데이터: JSON, HTML 등)

👉 추가적으로 Header도 있지만, “꼭 포함”되는 건 Status Code + Body. 경훈님이 말한 “상태코드는 ResponseEntity로 수동으로 넣어주는 거 아닌가?” → 맞아요. Spring에서는 ResponseEntity.status(HttpStatus.CREATED).body(...)처럼 직접 지정할 수 있어요.

 

Q3. 다음 중 RESTful API 설계 원칙에 맞는 것을 모두 고르시오.

1. /getUserInfo?id=1
2. GET /users/1
3. POST /createUser
4. POST /users

정답: 2번, 4번

/getUserInfo?id=1 → ❌ (행위가 URL에 들어가 있음 → 비RESTful)
GET /users/1 → ✅ (리소스: /users/1, 행위: GET)
POST /createUser → ❌ (행위가 URL에 들어감)
POST /users → ✅ (리소스: /users, 행위: POST)

 

Q4. GET과 POST의 차이를 설명해보시오.

 

정답:

GET: 조회(Read) 목적, URL에 파라미터가 포함될 수 있음. Body 거의 없음. POST: 생성(Create) 목적, Body에 데이터를 담아 서버에 전송.

👉 경훈님 답변 “GET은 조회, POST는 입력” → 아주 정확합니다 👍

 

Q5. 상태 코드(Status Code)의 의미가 잘못 연결된 것은?

1. 200 → OK (성공)
2. 201 → Created (리소스 생성 성공)
3. 204 → 서버 에러
4. 404 → Not Found

정답: 3번 (204)

200 → OK (성공) ✅
201 → Created (생성 성공) ✅
204 → No Content (성공했지만 반환할 바디 없음) ❌ 서버 에러 아님
404 → Not Found ✅

👉 204는 실무에선 자주 써요.
예: DELETE 요청 성공 시 “삭제 완료”를 응답하면서 별도 데이터는 필요 없을 때 204 No Content를 씁니다.

 

 

---

전 3번을 틀렸는데 조금 이상했습니다.

 

POST /createUser ❌
→ 동사(create)가 URL에 들어갔음. REST는 URL은 자원(명사), 메서드로 행위 표현이 원칙이에요.

 

 

근데 실습 시에 동사를 넣는다고 작동을 안하진 않습니다.

그렇기에 더 햇갈리더군요. 이에 대한 답은 간단했습니다.

1. 실제 동작 관점

POST /createUser 같은 URL도 잘 작동합니다. 서버 라우팅에서 저 경로를 매핑하면 → 컨트롤러가 응답을 줄 수 있으니까요. 즉, 동사가 들어가도 “망가지진 않음”.



2. RESTful 원칙 관점

REST는 “스타일(Style)”이에요.

권장: URL은 **자원(명사)**만, 행위는 HTTP 메서드로 표현. 위배: URL에 행위(동사)를 넣음 → REST 원칙에서 벗어난 디자인.

➡️ RESTful vs 비RESTful의 차이는 "잘못된 코드냐"가 아니라, “표준에 맞는 설계냐”의 문제예요.



3. 현업 맥락

작은 프로젝트나 개인 프로젝트에서는 /createUser, /getUserInfo 같은 패턴 흔히 씀. 하지만 대규모 서비스/팀 협업에선 RESTful 원칙을 지키는 게 유지보수, 확장성 면에서 훨씬 유리해요. 예: /users (POST, GET) → 동일한 URL에 메서드만 달리 써서 행위 표현 가능. /createUser, /getUserInfo → 엔드포인트가 늘어날수록 혼란 가중.

---

참고자료

 

// 컨트롤러 클래스: 요청(Request) → 응답(Response) 처리 담당
@RestController
@RequestMapping("/posts")
public class PostController {

    // GET /posts/1 요청을 처리
    @GetMapping("/{id}")
    public ResponseEntity<PostDto> getPost(@PathVariable Long id) {
        // 가짜 데이터 생성 (실제로는 DB 조회)
        PostDto post = new PostDto(id, "제목 예시", "내용 예시");

        // 응답 반환 (상태코드 200 OK + Body)
        return ResponseEntity.ok(post);
    }
}

 

실행 흐름

1. 클라이언트 → GET /posts/1 요청
2. 서버(Spring Boot Controller) → 요청을 매핑하고 PostDto 생성
3. 서버 → ResponseEntity.ok(post) 응답 (HTTP 200 + JSON Body)
4. 클라이언트 → response.json()으로 응답 확인