백엔드 구조
웹서버 - 웹 어플리케이선 서버 - 데이터베이스
모두 통틀어서 백엔드라고 한다. 웹 브라우저는 클라이언트도 될 수 있고, 프론트 개발분야라고도 할 수 있다.
- 웹서버 : 정적 페이지
동적페이지는 직접 처리하지 않고, 웹 어플리케이션 서버로 전달한다.
API : Application Programming Interface
운영체제와 응용 프로그램 사이의 통신에 사용되는 언어나 메시지 형식
라이브러리(데이터)에 접근하기 위한 규칙들을 정의한 것
Interface 인터페이스
중간에서 양단의 플랫폼을 중재, 매개체가 되어주는 역할이다.
방법
- GUI : 화면
- CLI : 글자 입출력
- NUI : 인간의 신체, 움직임, 음성, 터치, 홍채
- OUI : 현실에 존재하는 모든 사물이 입출력 장치가 될 수 있다.
REST API
웹 인터넷을 돌아다니기 위한 규약을 지켜야만 한다. == `HTTP` 지켜야 한다.
웹 가상 공간의 연결 프로토콜 : `http`
프로토콜 : 클라이언트와 서버간의 약속, 양식, 규칙
과거에는 형식을 따르지 않았지만, 창시자 왈 형식을 따르면 효율이 극대화된다..!!
`REST API` : HTTP 규약을 잘 따른 API VS `RESTful API` : HTTP 규약을 매우매우 잘 따른 API
HTTP 프로토콜 템플릿
인터넷 상에서 전달할 것들은 모두 HTTP에 넣어서 보내야 한다.
Head, Body로 구성
Head : 통신 상태, 응답 형태 전달
Body : 전달해줄 데이터 또는 화면, 필요한 데이터와 목적
요청방법 URL
웹페이지 위치 + 데이터 연산 해달라고 서버에 요청을 보내는 방법이 웹 페이지 주소이다.
http://localhost:8888/`전체상품조회`
kr 까지 고정된 도메인.
? 뒤에 동적 데이터 받아온, 변동되는 url
API 설계 실습
📝 <REST API URL 규칙>
- 대문자 X, 소문자 O
- 언더바(_) X, 하이픈(-) O
- 마지막에 / 포함 X
- 행위를 포함하지 않는다. = 목적
- 파일 확장자 포함X
- 복수형을 쓴다.
http://localhost:8888/post product - 상품등록 ⇒ "POST" /product
http://localhost:8888/select_all_products - 전체 상품 조회 ⇒ "GET" /products
http://localhost:8888/DeleteAllProducts - 전체 상품 삭제 ⇒ "DELETE" /products
ex. 쇼핑몰
쇼핑몰 메인페이지 → 전체 상품 조회 API → 전체 상품 데이터 받고, → 받은 데이터를 페이지에 뿌린다
상품 상세 페이지 틀 → 상품1 개별 조회 API → 데이터를 받아서 → 틀에 맞게 뿌려준다
상품 관리 페이지 → 전체 상품 조회 API → 데이터....
상품 수정 페이지 → 상품1 개별 조회 API // 완료버튼 → 상품1 수정 API
- 상품 전체 "조회" GET
- (http:localhost:8888) /products
- 상품 개별 "조회" GET
- /pruducts/{id}
- 상품 개별 "수정" PUT
- /product/{id}
* 복수형으로 표현하면 좋은 이유? 상품'들' 중에 id 값을 가지는 개별 데이터, 통일감 등의 이유!
☑️ 배운 점
그동안 이해하기 어려웠던 API 사용!!! 설계를 해보니 이해가 잘 된다.
실제로 코드 구성하면서, API 안에 정보가 왕창 많이 들어갈텐데, 더 복잡한 API 설계도 해보고 싶다.
기대중~~