TODO
RESTful API CS 특강(9~10)
DB특강(14~)
git 강의 2주차

RESTful API CS 특강

개념

Interface

어떠한 두가지가 서로 연결되고 영향을 미칠 수 있는 장소/방법/상황

Application Programming Interface(API)

• 응용프로그램 간에 데이터를 주고 받는 방법
  프로그램 혹은 시스템 간의 통신하는 창구, 즉 프로그램들이 서로 상호작용하는 것을 도와주는 매개체라 할 수 있다.
• 웹 API
  웹 API는 웹 애플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세를 일컫는다.
  예를 들어 블로그 API를 이용하면, 블로그에 접속하지 않고도 다른 방법으로 글을 올릴 수 있다.
  그 외에 우체국의 우편번호 API, 구글과 네이버의 지도 API 등 유용한 API들이 많으므로, 요즘은 홈페이지 구축이나 추가 개편 시 따로 추가로 개발하지 않고 이런 오픈 API를 가져와 사용하는 추세다.
• 엔드포인트는 서비스를 사용가능하도록 하는 서비스에서 제공하는 커뮤니케이션 채널의 한쪽 끝.
  즉 요청을 받아 응답을 제공하는 서비스를 사용할 수 있는 지점을 의미 한다.
• API가 두 시스템(어플리케이션)이 상호작용(소통) 할 수 있게 하는 프로토콜의 총 집합이라면, ENDPOINT는 API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL
  출처 - API 와 Endpoint ?

Server API

• 데이터를 주고 받는 양식
• 인증
• 호출제한

OpenAPI

• 빠르고 유연한 비즈니스 구축
• 비즈니스 품질 향상
• 생태계 확립
• 적은 비용
• 빠른 시스템 도입
• 비즈니스 품질 향상

REST의 정의

REpresentational State Transfer

자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미.
즉, 자원(resource)의 표현(representation)에 의한 상태 전달을 뜻함.

• 자원 : 해당 소프트웨어가 관리하는 모든 것 ( 문서, 그림, 데이터, 해당 소프트웨어 자체 등 )
• 표현 : 그 자원을 표현하기 위한 이름 ( DB의 학생 정보가 자원이면, 'students'를 자원의 표현으로 정함 )
• 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달. ( JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적 )
  REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에,
  웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일.
  REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나.

REST의 구성 요소

1. 자원(Resource) - URI

• 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재합니다.
• 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI 입니다.
• Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청합니다.

2. 행위(Verb) - Method

• HTTP 프로토콜의 Method를 사용합니다.
• HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공합니다. ( CRUD )

  GET	Read : 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청한다.
  POST	Create : 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보낸다.
  PUT	Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 전체를 바꿀 때)
  PATCH	Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 일부만 바꿀 때)
  DELETE	Delete : 정보 삭제, (안전성 문제로 대부분 서버에서 비활성화한다.)

3. 표현 ( Representation of Resource )

• Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있습니다.
• JSON, XML을 통해 데이터를 주고 받는 것이 일반적입니다.

GraphQL

기존의 REST API 는 설계규칙이 여러가지인데 그것을 일일이 구현하는 것이 힘들었음.

🔑 정보를 요청하는 쪽에서 원하는 형태로 정보를 가져오고 수정할 수 있는 Query Language

GraphQL이 해결 한것

• Over-Fetching

  • 필요한 정보보다 더 많은 데이터를 전달 받는 것
  • 불필요한 리소스 낭비가 발생
  • 필요한 정보만 골라내는 추가 작업이 발생

• Under-Fetching

  • 필요한 데이터를 만들기 위해 여러 번의 호출이 필요
  • 추가적인 리소스 요청이 발생
  • 여로 요청을 통해 전달 받은 정보를 조합하는 추가 작업이 발생

GIT

Branch

• 각자 맡은 것을 작업하기 위한 가지
• 현재위치 branch에서 commit이 되었는지 확인하고 새 branch를 생성.
• 삭제할때는 다른 branch로 checkout한 후 강제삭제해주기.

Merge

• 각자 작업한 파일을 프로젝트에 합치는 작업(병합)
• 특정 브랜치의 commit 들을 다른 브랜치의 commit 내역에 모두 반영하는 것
• branch를 나누면 브랜치마다 다른 파일을 수정해야함!! 안그러면 merge-conflict(병합 충돌)일어남.
• 병합이 될 기준 브랜치에 체크아웃 해준 뒤 상단바에서 병합을 눌러줌.
• 병합할 브랜치를 선택한 후 즉시 커밋 병합/ 병합 커밋의 메세지 첨부/ 빠른 병합이 가능해도 새 커밋생성 3가지 선택 해준 뒤에 병합눌러주기!
• 작업이 완료되어 브랜치의 내용을 머지한 후에는 헷갈리지 않도록 브랜치를 삭제해주는 것이 좋음.

추가정보얻기

STACKOVERFLOW
기술블로그
GIT문서

우준호튜터님 깜짝특강

• 통신 : 요청(request)/응답(response)
  클라이언트가 서버에 요청하고 서버는 응답.

• FE/BE : 작성한 언어를 어디서 해석하는가?

  • FE : 브라우저가 해석, 휴대폰 앱을 위해 만들어진 언어는 기계가 해석
  • Javascript 프론트용/ Node.js 백용

• 일대일/다대다/일대다
  '다'인애가 '일'인 애의 아이디를 가지고있는게 일반적