내배캠 TIL 21일차

학습 요약

Spring 입문 강의

---

Spring 입문 1주차

어제에 이어서 작성하도록 하겠습니다.

HTTP 1강

HTTP 요청 메세지 (Request Message)

1. 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) 에 해당하는 값도 포함한다.

    ex) /search?keyword=sparta

• HTTP Version
  • 1.1
  • HTTP Version을 나타낸다.

2. Header

• Host: spartacodingclub.kr
• field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조를 가진다.
• field-name은 대소문자 구분을 하지 않는다.
• 임의의 Header를 추가할 수 있다. (단, 서버가 값을 알고 있어야 함)
• 요청의 추가 정보들을 가지고 있다.
  ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등

3. Empty Line

• 공백 한 줄
• 필수 값

4. Message Body

• 실제 전송하는 데이터가 담겨 있는 부분
  • HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
• 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

HTTP 응답 메세지(Response Message)

1. Start Line

• HTTP Version
• Status Code
  • 요청이 성공했는지, 실패했는지 나타내는 코드
• Status Text
  • 코드와 함께 전달될 메세지

2. Header

• Response에서만 사용되는 Header 값들이 따로 존재한다.

3. Empty Line

• 공백 한줄, 필수값

4. Message Body

• 실제 전송하는 데이터가 담겨 있는 부분
• 만약 전송할 데이터가 없다면, Body가 공백으로 존재한다.

HTTP Method

클라이언트 - 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식

POST (생성)

• 주로 HTML FORM에 사용
• 요청 데이터를 처리하는 방식에 정해진 것은 없음
• Message Body를 통해 요청 데이터를 전달

GET (조회)

• 서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String(Query Parameter)를 사용

PUT (전체 수정)

• POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정
• 리소스가 없다면 생성

PATCH (부분 수정)

DELETE (삭제)

기타 Method

• HEAD : GET에서 Message Body를 제외하고 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능한 Method를 설명
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP 2강

HTTP Method별 속성표

출처: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

1. 안전성(Safe)

메서드를 호출해도 변경되지 않는 성질

2. 멱등성(Idempotent)

연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

3. 캐시가능성(Cacheable)

재사용을 위해 요청에 대한 응답을 저장할 수 있?

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

HTTP 상태 코드

• 1xx (정보)
• 2xx (성공)
• 3xx (리다이렉션)
• 4xx (클라이언트 에러)
• 5xx (서버 에러)

HTTP API 설계 방법

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

HTTP 3강

Restful API

REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원을 관리

자원은 고유한 URI로 식별되며, HTTP 메서드를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어짐

RESTful API 설계 규칙 및 Best Practices

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

Maturity Model (성숙도 모델)

REST의 제약 조건에 따라 API를 등급화하는 방법
Level0~3이 존재

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

1. Consumer first

• 개발자 중심의 설계방식보다 해당 API의 소비자 (또다른 시스템, 개발자 등) 입장에서 간단하고 직관적인 API를 설계

2. Make best use of HTTP

• HTTP Method와 Request, Response, Header와 같은 HTTP의 장점을 살려서 개발

3. Request methods

• 최소한 성숙도 모델 Level2로 사용

4. Response Status

• 각각의 API 요청에 따라서 적절한 HTTP 상태코드가 전달
• 성공했다, 실패했다가 아닌 왜 실패하고 성공 하였는지 함께 반환

5. No secure info in URI

• URI에는 사용자의 정보를 포함x

6. Use plurals

• 제공하는 데이터에 대하여 단수가 아닌 복수형태로 쓰는것이 일반적
• 특정 유저를 찾고자 한다면 엔드포인트에 값을 추가

ex) /user -> /users

ex) /users/1

7. User nouns for resources

• 모든 리소스는 가능하면 동사가 아닌 명사형태로 표시
• API URI만 보고도 어떠한 API인지 파악할 수 있는 것이 좋음

8. For exceptions - define a consistent approach

• 일괄적인 엔드포인트를 사용하는것이 좋음

Web Application 1강

Web Server

웹 서버는 HTTP 기반으로 동작하며 정적 리소스(HTML, CSS, JS, 이미지 등)를 제공

WAS(Web Application Server)

HTTP 기반으로 동작하며 웹 서버의 기능을 포함하고, 코드를 실행해서 Application 로직을 수행하고 DB와 상호작용하여 동적 컨텐츠를 생성

• WAS는 Application 코드를 실행하는 것에 더욱 특화
• Java에서는 Servlet Container 기능을 제공하면 WAS

느낀 점

스탠다드 반에서 3주차 강의까지 듣고 오라고 해서 최대한으로 이해하면서 듣고 싶었지만 3주차 부분은 아무리 이해를 하려고 노력해봐도 안 될 것 같아서 일단 이해는 접어두고 들었다. 이거 이해할 수 있는 건가? 목요일까지 5주차까지 들으라고 하는데.. 큰일났네..TIL도 많이 밀려쓸 것 같은데😭😭