1. 학습 목표
- RESTful한 설계방식에 대해 이해한다.
- Server to Server 통신에 대해 이해한다.
- 템플릿 구조에 대해 이해하고 실습해본다.
2. 6주차 수업 후기
💡 6주차 수업 듣고 느낀점 이야기, 각자 진행상황 공유저번 주차에 작성했던 API들을 보며 어떻게 해야 실제 환경에서 잘 동작하는 API를 설계할 수 있을까 고민했습니다. RESTFul 하게 API들을 만들기 위해 수정하는 과정에서 Validation과 같은 다양한 고민을 할 수 있어서 좋았습니다.
3. 실습
AWS RDS 서비스에 테이블 EXPORT 한 모습
GET /api/member/get/{idx} 사용자 정보 조회 API
PATCH /api/member/quit/{idx} 사용자 탈퇴 처리 API
업데이트 된 코드 Github 링크
실습 체크리스트
❗️ 이번 주차는 개념적인 내용보다는 REST API를 최대한 많이, 꼼꼼하게 설계&구현해보면서 템플릿에 익숙해지는 게 핵심입니다. 이번 과제 API 최소 개수는 10개이지만 가능한만큼 최대로 많이 만들어오시면 됩니다.
- 프록시 서버 설정 / 서버 무중단 배포 ( 스프링부트의 경우 7주차에 진행해주세요! )
- 지난 주 과제때 설계/구현한 API에 RESTful원칙을 적용하고 템플릿을 사용해서 구현하기
- API 추가 구현하기
- HTTP Method를 모두 사용해보기
- Path Variable, Query String, Body를 모두 사용해보기
- 형식적/논리적 Validation 추가하기
- API Sheet 작성 (Swagger 대체)
4. 핵심 키워드
- REST/RESTful Representational State Transfer의 약자로써, HTTP를 더 잘 활용하기 위해서 고안된 아키텍쳐입니다. REST API는 URI, HTTP METHOD, 표현으로 구성되며 Restful 한 API 설계를 위해서는 몇 가지 규칙들이 정해져 있습니다.
-
URI는 정보의 자원을 표현해야 한다.
-
자원에 대한 행위는 HTTP Method으로 표현
따라서 자원에 대한 CRUD API를 작성할 때는 URI + HTTP Method 만으로 이 API가 어떤 자원에 대해서 어떤 행위를 할 지 알 수 있어야 합니다.
-
- HTTP Method
- GET : CRUD의 Read에 해당합니다. 서버 상의 리소스를 읽고 가져오는 역할을 합니다.
- POST : CRUD의 Create에 해당합니다. 서버 상의 리소스를 새로 생성하는 역할을 합니다. Idempotent 하지 않아서 실행할 때 마다 같은 결과를 보장하지는 못합니다.
- PATCH : CRUD의 Update에 해당합니다. 서버 상의 리소스를 일부 수정하는 역할을 합니다.
- PUT : CRUD의 Update에 해당합니다. 마찬가지로 서버 상의 리소스를 수정하는 역할을 합니다. PATCH 메소드와 다른 점은 PATCH 메소드는 자원의 일부만 수정하는데 비해 PUT 메소드는 자원의 전체를 수정하는 메소드입니다.
- DELETE : CRUD의 Delete에 해당합니다. 서버 상의 리소스를 삭제하는 역할을 합니다.
- 이외의 다른 메소드
- CONNECT : CONNECT 메서드는 목표 리소스의 터널 연결을 체결하는 역할을 합니다.
- OPTIONS : OPTIONS 메서드는 목표 리소스와의 통신 옵션을 기술하는 역할을 합니다.
- TRACE : TRACE 메서드는 목표 리소스와의 루프 백 테스트를 수행합니다.
- HTTP Response Code 의미 5개의 클래스로 분류됩니다.
- 1XX : 요청을 받았으며 프로세스를 계속한다는 의미입니다. 101 코드는 요청자가 서버에 프로토콜 전환을 요청했으며 서버가 이를 승인하는 중이라는 의미입니다.
- 2XX : 요청을 성공적으로 처리했다는 의미입니다. 200 코드는 서버가 요청을 제대로 처리했다는 뜻입니다. GET Method에 200 Response 코드를 받았다면 서버가 요청한 리소스를 제대로 제공했음을 가르킵니다.
- 3XX : 요청 완료를 위해 추가 작업 조치가 필요하다는 의미입니다. 301 코드는 해당 요청이 들어오면 자동으로 새 위치로 전달됩니다. 리다이렉션에 대한 응답 코드입니다.
- 4XX : 요청의 문법이 잘못되었거나 요청을 처리할 수 없다는 의미입니다.
- 401 : 권한이 없는 경우입니다. 인증 실패 - 사용자가 누구인지 확인에 실패함
- 403 ; 서버가 요청을 거부하고 있는 경우입니다. 인가 실패 - 사용자가 요청에 대한 해당 권한이 없는 경우.
- 404 : 서버가 요청한 페이지를 찾을 수 없는 경우입니다.
- 5XX : 서버가 명백히 유효한 요청에 대해 충족을 실패했다는 의미입니다. 500 코드는 서버에 오류가 발생해서 요청을 수행할 수 없는 경우입니다.
- Reverse Proxy WAN에서 들어오는 요청을 LAN으로 들이기 전에 서버를 한번 거치게 하는 설게 방식입니다. 클라이언트 요청의 중간자로써 웹 서버가 응답하는 데이터의 버퍼링이나 보안 상에서 이점을 가져갈 수 있습니다.
5. 논의해보면 좋은 것들
각자 작성한 API Sheet를 살펴보면서 서로 피드백하는 시간을 가져보세요!
- API설계가 RESTful한지
- Response 데이터 구조는 적절한지
- Response에 빠진 데이터는 없는지
- Validation은 꼼꼼하게 처리했는지
- API Sheet가 보기 좋게 잘 정리되어 있는지
make maketh install