🌈 [Section2] 10. HTTP / REST API

현주·2022년 10월 4일

network 실습 코드스테이츠

bootcamp

목록 보기

29/71

📕 오늘 배운 내용!

REST API
Postman 실습

✏️ REST API

Representational State Transfer API
HTTP의 장점을 극대화 할 수 있는 네트워크 아키텍쳐
웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식
(URI를 어떻게 정의할건지에 대한 규칙)
➜ 제일 핵심은 리소스(URI) 식별

✔️ 리소스 (Resource)
데이터베이스에 저장된 데이터, 문서, 이미지, 동영상 등 HTTP 통신을 통해 주고 받을 수 있는 모든 것
클라이언트와 서버 사이에서 데이터와 리소스를 요청하고 응답할 때 따르는 규칙
( 이 규칙대로 요청과 응답을 진행해야함 )

[참고] https://docs.spring.io/spring-framework/docs/current/javadoc-api/

✔ REST 성숙도 모델

0단계 : HTTP 사용
⠀
➜ 단순히 HTTP 프로토콜을 사용하는 단계
⠀
➜ 이 API를 REST API라고 할 수는 없고, 그냥 기본 단계임

1단계 : 개별 리소스와의 통신을 준수
⠀
➜ 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 함
⠀
➜ 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 함
⠀
Ex. '어떤 리소스를 변화시키는지' 혹은 '어떤 응답이 제공되는지'에 따라 다른 엔드포인트
⠀
➜ 엔드포인트는 명사로 작성
⠀
➜ 응답할 때, 사용한 리소스 정보 + 리소스 사용에 대한 성공/실패 여부도 반환해야 함

✔️ 엔드포인트 적는 방법
CamelCase - 모두 붙여쓰고 단어의 시작은 대문자로 (맨앞은 대소문자 상관 없음)
Snake_case - 언더바로 단어 잇기
Spinal-case - 하이픈으로 단어 잇기 (URI 쓸 때 사용 - URI는 모두 소문자)
➜ 보통 CamelCase 사용하고 나머지는 거의 안씀

2단계 : HTTP 메서드 원칙 준수 ➜ CRUD에 맞는 적절한 HTTP 메서드를 사용 ➜ 여기까지 적용하면 대체적으로 잘 작성된 API라고 함

✔️ CRUD
대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성) - POST, Read(읽기) - PUT, Update(갱신) - PUT, Delete(삭제)를 묶어서 일컫는 말

3단계 : HATEOAS 원칙 준수

➜ 하이퍼미디어 컨트롤을 적용
( HATEOAS(Hypertext As The Engine Of Application State)의 약어 )

➜ 요청은 2단계와 동일하지만, 응답에는 리소스(URI)를 포함한 링크를 삽입하여 새로운 기능에 접근할 수 있도록 함
( 더 쉽고, 효율적으로 리소스와 기능에 접근할 수 있게 하는 트리거가 될 수 있음 )
⠀
Ex. 좌석 예약 시, 예약 가능 시간 확인 후에 그 시간대에 예약할 수 있는 링크 삽입 or 예약 완료 후 그 예약을 다시 확인할 수 있는 링크 삽입

[참고] https://cloud.google.com/apis/design?hl=ko
[참고] https://sanghaklee.tistory.com/57

✔ 자주 사용되는 HTTP 메서드

GET
➜ 특정 리소스 조회 (Read)
( 데이터의 수정 없이 데이터를 받기만 함 )
➜ body를 가지지 않아 query parameter 사용하여 리소스 전달
Ex. 좌석 조회, 검색해서 자료 보기
HEAD
➜ GET과 동일한 응답이지만, 응답에 body 가 포함되지 않음
POST
➜ 요청마다 새로운 리소스 생성 (멱등성 가지지 않음) (Creat)
( 예기치 못한 input으로 서버의 상태 변화나 부작용을 일으킬 수도 있음 )
➜ 잘 생성되면 응답은 201 created로 옴
Ex. 좌석 예약, 회원 가입
PUT
➜ 요청마다 같은 리소스 반환 (멱등성 가짐)
➜ 목적 리소스의 모든 현재 표시를 요청하는 값으로 교체 (전체 수정) (Update)
DELETE
➜ 특정 리소스 삭제
Ex. 회원 탈퇴
PATCH
➜ 리소스의 일부분만 수정 (Update)
Ex. 비밀번호 수정
OPTIONS
➜ 리소스에 대한 통신 옵션 설명
TRACE
➜ 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

✔️ 멱등성 (Idempotent)
➜ 매 요청마다 같은 리소스를 반환하는 특징

Ex.

멤버 등록 /members ➜ POST

멤버 목록 조회 /members ➜ GET

멤버 조회 /members/{id} ➜ GET

멤버 수정 /members/{id} ➜ PUT/PATCH

멤버 삭제 /members/{id} ➜ DELETE

Ex. 총 120개의 트윗 중 인덱스가 20~30인 트윗, 즉 열 개의 트윗만 가져온다고 할 때,
➜ GET /tweets?offset=20&limit=10 로 요청
➜ 정보 가져와 / 트윗 정보 / 거기서 20부터 10개
⠀
( Query Parameter 중 offset(현재 위치), limit(컨텐츠 수)가 관습적으로 사용됨 )

✔ 자주 사용되는 HTTP 상태코드

( 응답할 때 보내는 것 )

200 : OK
➜ 성공적으로 응답을 마침
201 : CREATED
➜ 새로운 리소스가 생성됨
204 : NO CONTENT
➜ 리소스가 성공저으로 삭제되어 내용이 없음
302 : Found
➜ 리다이렉트할 URL을 확인함
304 : NOT MODIFIED
➜ 요청된 리소스를 재전송할 필요가 없음
( 요청한 리소스의 변경시간과 크기등이 원래 있던 거랑 서로 같음 )
400 : BAD REQUEST
➜ 요청이 잘못되었거나 처리할 수 없음
401 : UNATHORIZED
➜ 요청에는 사용자 인증이 필요
403 : FORBIDDEN
➜ 서버가 요청을 이해했지만 거부하거나 액세스가 허용되지 않음
404 : Not Found
➜ 클라이언트가 잘못된 페이지를 서버에 요청하여 페이지를 찾을 수 없음 ( URI 뒤에 리소스가 없음 )
406 : Not Acceptable
➜ 클라이언트가 응답 코드를 받을 수 없음
409 : Conflict
➜ 요청이 현재 서버의 상태와 충돌될 때
500 : Internal Server Error
➜ 서버에서 에러가 발생함
503 : Service Unavailable
➜ 현재 서버가 문제가 있어 사용이 불가능한 상태임

1xx - 정보 확인 (거의 사용 X)

2xx - 통신 성공

3xx - 리다이렉션 필요 (추가적인 작업이 필요할 때)

4xx - 클라이언트 오류 (클라이언트에서 잘못 요청을 보냈을 경우)

5xx - 서버 오류 (서버가 죽어있을 때, 서버에서 오류가 났을 때)

[참고] https://developer.mozilla.org/ko/docs/Web/HTTP/Status

✏️ Open API 와 API Key

✔ Open API

누구에게나 열려있는 API
but, 기관이나 API마다 정해진 이용 수칙이 있고, 그 이용 수칙에 따라 제한사항(가격, 정보의 제한 등)이 있을 수 있음

Ex. 날씨 API - https://openweathermap.org/api

✔ API Key

서버의 문을 여는 열쇠
➜ 서버에서 요청에 응답할 때 필수적으로 비용이 발생하게 되는데, 이 때 서버 입장에서 아무런 조건 없이 데이터 제공해줄 의무 없음 ➜ 로그인으로 이용자를 제한하여 API Key의 형태로 제공해서, 데이터를 요청할 때 API key를 같이 전달해야만 원하는 응답을 받을 수 있도록 함