면접질문 RestAPI, 웹 기본(통신), 세션 쿠키

너무 오랜만이라 어떤 글을 쓸지 고민이 많았는데...

내가 하는 공부가 매일매일 해도 보여지지 않아서.. 억지로 git에 커밋하지 않는 한 보여지지 않는 게 아쉬워서 다시 조금이라도 꾸준히 써보려고 한다.
우선 요즘 면접 때 들었던 질문에 대한 답, 그리고 기본적인 cs지식을 차근차근 정리해 보려 한다.

우선 면접에서 실제 들었던 면접 질문 그리고 그 답들을 정리해 보려한다.

1. Rest API란?

-> REST API는

RestFul한 api를 말하며 일련의 특징과 규칙 등을 지키는 api를 일컸는다.

Rest는 웹서버에 있는 자원과 자원의 상태 등을 전송하는 방식을 말한다.

http 같은 프로토콜 위에서 리소스를 uri로 구분하고, get, post, put, delete 등으로 작업을 표시하는 방식

Restful api의 특징

• Uniform Interface: HTTP 표준만 따르면 플랫폼에 상관없이 사용 가능한 일관된 인터페이스를 가집니다.
• Stateless (무상태성): 서버는 클라이언트의 상태를 저장하지 않습니다. 클라이언트의 요청만으로 모든 처리가 가능해야 하며, 이는 서버의 확장성을 높여줍니다.
• Client-Server 구조: 자원을 가진 서버와 요청을 하는 클라이언트가 명확히 분리되어 있어 각각 독립적인 개발과 확장이 가능합니다.
• Cacheable (캐시 처리 가능): HTTP의 캐싱 기능을 적용할 수 있어 효율적인 네트워크 사용이 가능합니다.

1-1 Get vs Post차이

Get : 리소스 조회, URL의 쿼리 스트링 명시적 (민감한 정보를 보내기엔 부적절),

멱등성 O 여러번 해도 결과 동일 -> 여러번 조회해도 같은 값이 나옴

Post : 리소스 생성, Http Body 숨켜짐,

멱등성 x -> (카운터 버튼): 누를 때마다 숫자가 1, 2, 3...으로 올라갑니다. 누르는 횟수에 따라 결과가 매번 달라짐

 

1-2 Put vs Patch차이

Put : 대상 리소스의 전체를 업데이트, 만약 보내지 않은 필드가 있다면, 그 필드는 보통 null이나 기본값으로 덮어씌워짐.

Patch : 리소스의 일부 필드만 변경. 수정하고 싶은 값만 보내면 나머지 데이터는 그대로 유지

 

1-3 GraphQL

기존 REST API의 한계를 극복하기 위해 만들어졌으며, 핵심은 "클라이언트가 필요한 데이터의 구조를 직접 정의해서 요청 한다."

쿼리언어

사용 이유

REST API로 개발하다 보면 필연적으로 마주치는 두 가지 비효율을 해결

1. Over-fetching (오버페칭) : 사용자 이름만 필요한데 서버는 주소, 전화번호, 이메일까지 다 보냄.

2. Under-fetching (언더페칭) : 내 정보'와 '내가 쓴 댓글'을 보려면 /users/1 호출 후 /comments?user_id=1을 또 호출해야 함 (N+1 문제와 유사한 다중 호출).

• 해결: 한 번의 쿼리로 유저 정보와 하위 댓글 리스트를 묶어서 가져옴.

REST API vs GraphQL (면접용 비교)

구분	REST API	GraphQL
엔드포인트	자원마다 다름 (/users, /posts)	단 하나 (/graphql)
데이터 결정권	서버가 정한 대로 줌	클라이언트가 원하는 대로 받음
HTTP 상태 코드	200, 404, 500 등 다양하게 활용	대부분 200 OK로 오고, 에러는 Body에 담김
캐싱	HTTP 표준 캐시(브라우저 단) 활용 쉬움	HTTP 캐시 활용이 어려움 (별도 라이브러리 필요)

 

2. HTTP 에러코드 (400 vs 500)

4xx (Client Error): "요청이 잘못됨"

• 클라이언트가 보낸 데이터나 주소가 틀렸을 때 발생해. 서버는 정상인데 너(클라이언트)가 고쳐서 다시 보내야 해.
• 400 (Bad Request): 파라미터 타입이 틀리거나 필수 값이 없을 때.
• 401 (Unauthorized): 누구인지 모름 (로그인 필요).
• 403 (Forbidden): 누구인지는 아는데, 이 페이지를 볼 권한이 없음 (일반 유저가 관리자 페이지 접근).
• 404 (Not Found): 요청한 URL 주소가 잘못됨.

5xx (Server Error): "서버가 터짐"

• 요청은 잘 왔는데, 서버 로직(Java 코드)에서 에러가 나거나 DB가 죽었을 때 발생해.
• 500 (Internal Server Error): 가장 흔함. 코드에서 NullPointerException 같은 예외가 터졌을 때.
• 503 (Service Unavailable): 서버 점검 중이거나 사람이 너무 많이 몰려서 응답 불가.

 

3. 사용자 식별 (쿠키 vs 세션 vs JWT)

"로그인 유지를 어떻게 하나요?"라는 질문에 대한 핵심 비교야.

구분	쿠키 (Cookie)	세션 (Session)	JWT (Token)
저장 위치	클라이언트(브라우저)	서버 메모리/DB	클라이언트
보안성	낮음 (탈취 쉬움)	높음 (서버가 관리)	중간 (암호화됨)
확장성	높음	낮음 (서버 동기화 필요)	매우 높음 (무상태성)

• 세션 방식: 서버가 "철수"라는 정보를 메모리에 들고 있고, 철수한테는 "번호표(세션ID)"만 줘. 보안은 좋지만, 서버가 여러 대(Scale-out)가 되면 모든 서버가 철수 정보를 공유해야 해서 복잡해져.
• JWT 방식: 아예 철수의 정보를 암호화해서 티켓(Token)으로 만들어줘. 서버는 저장 공간이 필요 없어서 무상태성(Stateless)을 유지하기 좋고, 마이크로서비스(MSA)에서 아주 유리해.

3-1 CSRF 공격

쿠키를 쓰면 왜 위험한가요?라는 꼬리 질문에 대한 답변.

• 정의: 사용자가 로그인된 상태에서, 공격자가 만든 가짜 사이트를 클릭했을 때 사용자의 의도와 상관없이 서버에 위험한 요청(비밀번호 변경, 송금 등)을 보내는 공격.
• 왜 가능할까? 브라우저는 해당 사이트로 요청을 보낼 때 쿠키를 자동으로 실어 보내기 때문. (서버는 "철수 쿠키가 왔네? 철수가 보낸 거구나!" 하고 믿어버려.)

대응 방법

1. CSRF 토큰: 서버가 매번 임의의 토큰을 발행해서, 이 토큰이 없는 요청은 거부하는 방식.
2. SameSite 설정: 쿠키를 구울 때 SameSite=Strict 옵션을 주면, 다른 사이트에서 보낸 요청에는 쿠키가 포함되지 않는다.