🦋 REST API
- Representational State의 약자
- 웹에서 사용되는 데이터나 자원을 http uri로 표현하고, http프로토콜을 통해 요청과 응답을 정의하는 방식
- 메뉴판이 겁나 읽기힘들다면 주문이 어렵겠죠? 클라이언트와 서버사이에도 데이터와 리소스를 요청하는 메뉴판이 필요함.
- 알아보기 쉽고 잘 작성된 메뉴판 만들기가 REST API 디자인임
- 웹페이지 사용자는 프론트엔드 개발자가 만든 버튼으로 http메서드에 간접적으로 접근하나요? o
- 성숙도 모델은 0~3단계까지 4개, 2단계까지만 적용해도 좋은 디자인
🦋 REST 성숙도 모델 0단계
- 0단계에서는 단순히 HTTP 프로토콜을 사용하기만 해도 됨
- 허준이란 주치의의 예약시간을 확인하고, 특정시간에 예약하는 상황
- 이처럼 http 프로토콜을 사용하고 있는것을 확인할수 있음
🦋 REST 성숙도 모델 1단계
- 1단계에서는 개별 리소스와의 통신을 준수해야 함
- 쉽게말해 웹에서 사용되는 모든 데이터나 자원을 http uri로 표현하는데, 모든 자원은 개별 리소스에 맞는 엔드포인트를 사용해야하며
- 요청하고 받는 자원에 대한 정보를 응답으로 전달해야 한다는것이 1단계의 핵심.
- 0단계에서는 요청에서의 엔드포인트로 모두 /appointment를 사용했음
- 1단계에서는 요청하는 리소스가 무엇인지에 따라 다른 엔드포인트로 구분함
- 위의 예시에서 예약가능한 시간 확인이라는 요청의 응답으로 받게되는 자원은 허준이라는 의사의 예약 가능한 시간대이다. 그렇기 때문에 요청시 /doctors/허준 이라는 엔드포인트를 사용한 것을 볼 수 있다.
- 특정시간에 예약하게 되면, 실제 slots라는 리소스의 123이라는 id를 가진 리소스가 변경되기 때문에, 하단의 특정시간에 예약이라는 요청에서는 /slots/123으로 실제 변경되는 리소스를 엔드포인트로 사용함
🦋 REST 성숙도 모델 2단계
- 2단계는 CRUD에 맞게 적절한 HTTP 메서드를 사용하는것에 중점을 둠
- 0,1단계는 CRUD(Create,Read,Update,Delete)와 상관없이 POST메서드를 씀
- 예를들어 예약가능한 시간을 확인한다는건 예약가능한 시간을 조회(READ)하는 행위를 의미하고, 특정시간에 예약한다는 것은 해당 특정시간에 예약을 생성(CREATE)한다는 것과 같다. 그렇기에 조회(READ)하기 위해서는 GET메서드를 사용하여 요청을 보내고 이때 GET메서드는 body를 가지지 않기 때문에 query parameter을 사용하여 필요한 리소스를 전달합니다.
- 또한 예약을 생성(CREATE)하기 위해서는 POST 메서드를 사용하여 요청을 보내야하며, POST요청에 대한 응답이 어떻게 반환되는지가 중요
- 이경우 응답은 새롭게 생성된 리소스를 보내주기 때문에, 응답코드는 201 Created로 명확하게 작성해야 하며, 관련 리소스를 클라이언트가 Location헤더에 작성된 URI를 통해 확인할 수 있도록 하면 완벽하게 REST성숙도 모델의 2단계를 충족한 것이라고 볼 수 있다.
HTTP 메서드
- GET은
- POST는
- PUT은 멱등성 있음. 전체를 바꾸는 메서드
- PATCH는 멱등성 없음. 일부를 바꾸는 메서드
- GET메서드같은경우 서버의 데이터를 변화시키지 않는 요청에 사용해야 함
- POST 메서드는 요청마다 새로운 리소스를 생성하고 PUT메서드는 요청마다 같은 리소스를 반환한다.
HTTP 메서드 사용할 때 지켜야할 규칙
- 위처럼 매 요청마다 같은 리소스를 반환하는 특징을 멱등(idempotent)하다고 함
- 멱등성을 가지는 PUT, 그렇지 않은 메서드 POST는 구분하여 사용해야 함
- PUT과 PATCH메서드도 구분하여 사용해야 한다. PUT은 교체, PATCH는 수정의 용도로 사용함
- 2단계까지 만족하면 HTTP API라고 부름. 3단계부터 REST성숙도
🦋 REST 성숙도 모델 3단계
- 마지막단계는 HATEOAS라는 하이퍼미디어컨트롤을 적용
- 3단계의 요청은 2단계와 동일
- 3단계의 응답은 리소스의 URI를 포함한 링크요소를 삽입하여 작성해야함
- 예를들어 의사의 예약가능시간을 확인후에는 그시간대에 예약을 할수있는 링크를 삽입하거나, 예약완료후 다시 확인할수있도록 링크를 작성해 넣을수도 있다.
- 응답내에 새로운 링크를 넣어 새로운 기능에 접근할수 있도록 하는게 3단계의 핵심
🦋 OPEN API
- 누구에게나 열려있는 API
- 가격, 정보가 무제한은 아님
- 예를들어 Open Weather Map 사이트 날씨 API는
- 제한적이나마 무료로 날씨 API를 사용할수 있다. 분당 60번
- 데이터를 JSON형태로 응답
- 대부분 가입하고 키받고 URL에 쓰는 형식
🦋 API Key
- API를 이용할때 필요한 암호
- 자원접근권한을 서버가 부여하는 형태
🦋 Postman
- 웹 개발에서 사용하는 대표적인 클라이언트는 브라우저
- 브라우저는 서버에 http요청을 보낼 수 있는 훌륭한도구이지만, 주로 웹페이지를 받아오는 GET요청에 사용
- 브라우저 주소창에 URL을 입력하면, 해당 URL의 루트-엔드포인트로 GET요청을 보냅니다.
- 테스트를 위해 GET요청이 아닌 다른 요청을 보내려면, 개발자도구의 콘솔창에서 Web API fetch를 사용해야 한다.
- HTTP요청을 테스트할수있는 API테스트 도구를 써보자
- Postman으로 API를 테스트하고 날씨를 받아와보자
이미 API서버가 있고 주어진경우
- HTTP로 소통하기 위해서는 API서버의 endpoint가 URL로 주어져야 한다.
- root-endpoint : 서버가 요청을 수락하는 시작점
- endpoint : 메소드는 같은 URL들에 대해서도 다른 요청을 하게끔 구별하게 해주는 항목이 바로
'Endpoint'입니다.
- endpoint는 GET www.naver.com:3000/webtoon 이런걸 포함한것까지 말하는듯?
- HTTP Method : GET, POST, 이런애들임. URL과 같이 씀
- Query Parameter : users?kimcoding
- Path Parameter : users/kimcoding
🦋 5 Basic REST API
- GET, DELETE는 body를 쓰지 않는다.
- HEAD 는 잘 안씀
- POST, PUT, PATCH는 body를 쓴다.
- 엔티티 헤더 : 컨텐트에 대한 내용을 말하는 것
-
중요함. 프론트에서 많이쓰는 쿼리파라미터
-
페이지네이션 ?페이지하나당&30개게시물 보여줘
-
필터링 ?공개여부
-
정렬 ?역순
-
검색 ?=검색어
-
상태코드
-
200대 ok
-
304 반복된 요청시 브라우저 내 저장장소인 캐시에 저장된걸 그대로 보여줌
-
400대 오류, 프론트엔드 문제
-
500대 오류, 백엔드 서버문제
🦋 백엔드와 만나서 맨처음 하는 API 작성
- 유저정보에 대한 API 작성
& 성공 : 200 OK, 실패 : 400, 404
- 전체 유저 정보를 조회 : GET/users
& 성공 : 200 OK, 실패 : 400, 404
- 개별 유저정보를 조회 : GET/users/kimcoding
& 성공 : 201 Created 200 OK / 실패: 400, 409 Conflict
- 개별 유저정보 추가 : POST/users (post는 구체적내용이 body에 담기므로 구구절절 쓸필요없다, 그리고 같은 url이라도 백엔드입장에선 http메서드에 따라서 데이터 로직을 다르게 구성하므로 /users도 상관없음)
& 성공 : 200 OK 실패: 400, 404 (400은기본으로 들어감)
- 개별 유저정보 갱신 : PUT, PATCH /users/kimcoding
& 성공: 204 No Content, 200 OK, 실패: 400, 404
- 개별유저정보 삭제 : DELETE /users/kimcoding
API 사용법
- open api 에서 GET한 객체데이터를 fetch(axios)해서 갖고와야함
- postman으로 메서드 URL한 결과를 확인할수 있다.
++
- 상태끌어올리기 이해하면 목요일은 쉽다 : main의 상태를 바꾸고싶어서 Search한테 상태변경함수를 맡긴다
원래 배운건 state를 props로 내리는 것 까지였는데 이제 배우는건 setState 함수를 props로 내리는 것인가요 - userEffect 어렵고, 시간 많이 쓰도록 하자.
