이번 주 한 일
특강이 유난히도 많았던 이번 한 주.
솔직히 스파르타에서 제공해준 특강보다 내가 찾아봐서 공부한 것들이 얻은 게 더 많은 것 같긴 하다.
이번 주에 배운 것들은 TIL로 기록했으니 주말 동안 배운 것들을 기록해보려고 한다.
API
첫 미니 프로젝트 때부터 RESTful API에 대해서 귀에 피나게 들었지만 아직도 API가 무엇인지 정확하게 모른다는 생각이 들어서 다시 깊게 공부하는 시간을 가졌다.
API의 개념과 REST API에 대해 사이다로 정리해준 글을 발견해서 공유해본다.
프론트엔드와 백엔드가 소통하는 엔드포인트, RESTful API
다음은 위 글에서 내가 필요한 부분만 발췌해서 정리한 내용이다.
Web API란
- 다른 애플리케이션이나 데이터베이스로 가는 입구
- HTTP에서 일어나는 인터페이스
- REST는 통신을 통해 '자원의 표현된 상태'를 주고받는 것에 대한 아키텍처 가이드라인
JSON은 단지 데이터베이스에 저장되어있는 원본 데이터 리소스의 현재 상태를 표현한 것
POST /users/2/delete이 엔드포인트의 URI에는 삭제 행위를 의미하는 delete라는 표현이 포함되어 있다. 뭐 사실 이대로도 이 API가 어떤 역할을 수행하는 API인지 인지하기에는 큰 무리가 없지만, RESTful API는 URI를 사용하여 행위를 표현하지 않을 것을 권고한다. URI가 가지는 의미는 철저히 어떤 리소스인지, 그리고 리소스의 계층 구조에 대한 것 뿐이어야한다.
URI의 구조
일반 URI는 다음과 같은 형태를 나타낸다.
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
- scheme : 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용
- user와 password : (서버에 있는) 데이터에 접근하기 위한 사용자의 이름과 비밀번호
- host와 port : 접근할 대상(서버)의 호스트명과 포트번호
- path : 접근할 대상(서버)의 경로에 대한 상세 정보
- query : 접근할 대상에 전달하는 추가적인 정보 (파라미터)
- fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보
이외에 로그인 기능을 구현하기 위해 배경지식들을 공부했는데 그 내용들은 한꺼번에 포스팅해보려고 한다.
To-do list
- 팀원들과 함께 DB 설계해서 통일하기
- request, response 데이터 타입 정의하기
- RESTful API 수정하기
- session id 저장하는 법 연구
Back-End Wep Developer. 꾸준함이 능력이다.