데이터 전송 방법에 대해
개발자 입장에서의 통신?
두 컴퓨터 간의 데이터 전송!
이 두 컴퓨터가 데이터 전송을 하기 위해서는 이를 도와주는 프로그램을 설치하면 된다. (+ 인터넷연결)
FTP : 파일트랜스퍼프로토콜
SMTP : 심플메일프트랜스프로토콜
HTTP : 하이퍼텍스트트랜스퍼프로토콜
공부 할 것 : HTTP / API / Graphql / Rest
HTTP
두 개의 컴퓨터가 인터넷 연결이 되어 있다고 할 때 (프론트 <> 백엔드, 서버) 텍스트나 HTML 전송
요청 <-> 응답
<요청>
프론트 컴퓨터에서 작성자, 비밀번호, 제목, 내용을 state 에 담아 -----> 등록 요청 : 텍스트 { 객체 }로 만들어서 보냄 -----> 서버 컴퓨터에서 받아서 -----> DB 컴퓨터로 보냄 (Excel에 저장)
<응답>
백에서 완료 되었음을 응답 (텍스트, 객체) ----> 프론트에서 받음
상태코드도 같이 옴 (ex. 200 : 성공 )
HTTP 상태코드 mdn
API
각각의 요청을 처리하는 담당자, 해당 요청을 처리하는 함수
ex.게시물 저장 API, 프로필 저장 API, 프로필 조회 API etc..
둘 다 http 통신을 위한 것, 형태가 다를 뿐
REST : REST-API
- 주소처럼 생긴 이름
- lcalhost:3000/boards/new
- lcalhost:3000/boards/profile/철수
- axios 설치
GRAPHQL : GRAPHQL-API
- 페이스북에서 많은 데이터를 처리하기 위해
- 일반 함수 같은 이름
- board(1)
- profile("철수")
- apollo client 설치
⭐️ 왜?? 사용하세요?
큰 규모의 서비스일 경우...
- rest-api 에서는 필요한 데이터만 요청하지 못하기 때문에 N번 게시물에 대한 전체 내용을 요청하고 -> 불필요한 데이터까지 받아오게 됨 -> 네트워크 비용의 부담 증가
- graphal-api 에서는 필요한 데이터만 요청할 수 있어서 (ex.N번 게시물의 작성자와 제목만) -> 필요한 데이터만 받아 보내줄 수 있음 -> 네트워크 비용의 부담 감소
Json
- javascript object notaion (자바스크립트 객체 표기법)
- 주고 받는 데이터의 형태 --> 자바스크립트 객체처럼 생겼음
헤더
-
요청, 응답에 대한 요약정보를 보여준다
-
보내는이 : 백엔드 컴퓨터 or 사이트 주소(F)
-
보내는 내용 형태 : application/json
CRUD
- create(생성) read(수정) update(삭제) delete(조회-엑셀 변경x) 🌸 + 1 (read => detail/list)
- 최소한의 기능을 구현하기 위해서 필요함
- rest : post(c) put(u) delete(d) get(r)
- graphql : mutation(c, u , d) query (r)
- 사용하는 방법
🌟 둘 다 공부해야 하는 이유
1. 우리가 취업할 회사에서 어떤 것을 사용할 지 모름
2. public-API(오픈API)는 대부분 rest-api로 제공
정리하기
restful
- 이름은 모두 같게 만들고, 메서드를 통해 각기 다른 함수를 실행하는 방법
- 백엔드에서 어떻게 만들었느냐에 따라 달라지는 것. 모든 rest api가 restful 한 것은 아니다.
데이터 전송 실습
PostMan : rest-api
스웨거에서 api-docs 를 만들어서 주면, 포스트맨에서 실습
똑같은 /borad
이름은 같은데 api 가 다르다,
구분은
여기로 하자! => restful
restful 하지 않은 방식
더 효율적이고 실무에서 많이 쓰는 방식은 restful
요청하면?
예상 결과
등록 요청을 하면?
예상결과
연습 사이트
koreanjson.com
이곳도 restful한 api를 사용하고 있다.
이름이 같고, 메서드만 다른!
vs코드에서는 이렇게 사용한다
- endpoint 앞에는
https://~~~도메인 주소가 들어가야하는데
쓰고 뒤에는 엔드포인트까지!
1,2,3 그런 값은 이 내용이다!
postman에서 get 방식과 endpoint를 입력
하면 해당 데이터(JSON)를 가져와준다!
Playgrond : graphql-api
query 조회
mutations DB를 수정하는 것들
restapi는 주소만 작성하면 바로 데이터를 받아왔었다.
graphql은 자기가 받고 싶은 데이터를 정해주어야 한다.
받고 싶은 것은 return 에서 고르자.
반드시 1개 이상은 꼭 적어야한다!
만약 전부 다 쓴다면 restapi처럼 쓰는 거겠지?
플레이그라운드가 프론트엔드 화면이라고 생각하고
play 버튼을 누르면 백엔드로 요청이 간다.
빠른 속도로 요청이 처리 되고 데이터베이스에 저장되었다가, 결과를 다시 보여주는 것이다.
결과는?
이제 데이터를 보고 싶으면?
1개만 보는 것과 목록을 보는 것은 return 이 다르다
목록은 [ ] 배열로 받아오게 된다.
이름은 같은 이름이 있을 수 있기 때문에 id 으로 구분해서 사용함
이런 return 값은 백엔드 개발자와 조율해서 추가가능함
목록 api의 경우
게시글 수가 100~~~ 이상이 되어버리는데 page를 백엔드에서 지정준다.
1페이지에 보통 10개정도를 끊어서 보여주게 된다.
이렇게 페이지를 구분하자.
수정할 때 !
수정 해야 할 것의 id와 create할 때처럼 input 내용을 보내주기
이와 같은 !는 프론트에서 반드시 보내줘야 할 것!
추가학습 주제
HTTP 응답 상태코드 404는 무엇을 의미하나요?
404 Not Found
서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있습니다. 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.
HTTP메서드 PUT과 PATCH는의 차이는 무엇인가요?
PUT : 리소스의 모든 것을 업데이트 한다. => 만약 요청 시 보내지지 않은 값에 대해서는 null 값으로 변함
PATCH : 리소스의 일부를 업데이트 한다. => 요청에 포함되어 있는 부분만 변경이 된다
rest-API의 언더페칭, 오버페칭 은 무엇을 의미하나요?
언더페칭 : 데이터를 요청하고, 추가 데이터를 또 요청해야 하는 것
오버페칭 : 내가 필요한 데이터보다 훨씬 더 큰 데이터를 받게 되는 것
오늘 공부를 돌아보며
과제를 빨리 끝냈다... 행복~
조금조금 손에 익어가는 기분!
잘 하고 있는거겠지?
