인터넷 세상 (2024.04.26)

YJ·2024년 4월 29일

Spring

프디아 - 클라우드 기반 백엔드 개발(Spring) 프로그래밍

목록 보기

2/22

블로그 작성법
목표 > 공부한 내용 > 얻었고, 앞으로 이걸 해봐야지 적기

✋ 수업 목표

웹에 대한 전반적인 배경을 학습하자
HTTP와 API에 대해 배워보자

🤔 공부한 내용

1. 웹 개요

프로젝트란?

프로젝트의 기준
1. 네이버 계산기를 만든다 -? 프로젝트 맞음
2. 네이버에서 링크를 타고 들어갔는데 에러가 난다 -> 프로젝트 아님
일정 기간 일정 목적을 달성하기 위한 업무 묶음(프로세스)

인터넷 vs 웹

인터넷이란?
International Network
지구상에 있는 모든 공간이 연결 되어 있다.
연결망 그 자체를 얘기하는 것이다.
즉, 하나의 인프라, 신경망 이라고 생각하자.
웹이란?
웹의 시초 사이트를 찾아가보자.

전 세계 통틀어서 처음 생성된 웹 사이트이다.

웹이 만들어진 유례
팀 버너스리랑 동료들이랑 얘기를 했다.
너 A 알지? 나 알지
다른 사람한테 또 가서 너 A 안다며?
...
이렇게 100명 한테 말하려니 너무 힘들었다.
어짜피 인터넷은 연결되어있으니
가상 게시판 만들고 거기다가 똑같은 정보 실어놓자.
그러면, 나를 찾아오지 않고 가상 공간에 있는 정보를 찾겠지.

참고자료
https://www.tcpschool.com/webbasic/www

웹의 시초 info.cern.ch

웹의 목적은 우리 모두를 위한 정보 공유의 장
html: hyper text markup language
초능력을 가진 텍스트

<h1>안녕하세요</h1>
<p>안녕하세요</p>

우리는 글자에 의미를 담아서 세상의 모든 사람들이 글자를 이해할 수 있도록
할 수 있는 사명감을 가지고 개발할 수 있다.

HTTP

Hyper Text Transfer Protocol
받는 사람, 인사, 말, 끝인사, 보내는 사람

우리는 웹이라는 공간을 어떻게 찾아가는 걸까?
나 웹 보러가는 중이야
나 웹이 목적이야

예를 들어 편지를 다음과 같이 써보자.

공가져와
유준이가
...
유준에게
풋살 ㄱㄱ

이런 식으로 이상한 형식으로 편지를 작성하면 올바른 고객에게 편지를 보낼 수가 없을 뿐더러, 내용을 이해하기도 어려울 것이다.

HTTP는 이처럼 웹 상에서 올바르게 통신하기 위한 규약 이라고 생각하자.

HTTPS

인증서가 있는 순간 서버, 사용자가 검증된다.

다시 검색을 해보자.
https -> https 로 검색해보자.
그래도 https로 변환되어 검색된다.

인증서는 언제 적용하는게 좋을까?
개발 전에 인증서를 설정하고 하는게 좋을지, 아니면 개발을 다하고 인증서를 설정하는 것이 좋을지
인증서는 파트너사에게 맞기고, 개발이 다 진행되고 유저 테스트를 할때 인증서를 적용하자.

우리가 만드는 건 API

"RESTful API"
고전 API: 모든 데이터, 틀 X
틀, 규칙, 필요한 데이터만

우리가 사용한 API(Application Programming Interface)가 무엇인지?
인간 세상이 먼저 생겼다.
모든 용어는 인간 세상의 비슷한 개념을 가져다가 사용한다.
단어 뜻 부터 하나씩 파보자.

Application을 "Programming 하는데" 필요한 Interface 인가?
"Application을" Programming 하는데 활용하는 Interface 인가?

응용 프로그램: 사용자가 일반 유저인 프로그램
여러 사용자들을 대상으로 프로그램을 만들때 사용하는 인터페이스이다.

-> 인터 페이스 // ->

어플리케이션(내 프로젝트)을 "프로그래밍 하는데" 필요한 인터페이스
오른쪽에 있는 애들을 가려주기 위해서
오른쪽 애들이 엄청 복잡해서 가려주기 위해서
= 내가 구현하는 데 필요한 인터페이스
ex. 데이터, 자료구조/알고리즘, ...

"어플리케이션(남의 프로그램)을" (내 플젝) 프로그래밍 하는데 활용하는 인터페이스
= 니 프로그램 안에 연산, 데이터 ... 쓰고 싶을 때

만약에 신한에서 주식 서비스를 제공해주는 것을 API로 제공하는게 아니라, 직접 프로그램 코드를 제공할 경우...
1. 신한의 보안성이 떨어짐
2. 코드를 분석하고 사용하는데 오랜 시간이 걸림

그래서,,,
직접 접근하는 것이 아니라 사용법을 알려줄 테니... 그거보고 요청해

내가 사용하고 싶은 다른 프로그램과 기능을 그 프로그램에 직접 접근 없이도 거기서 제공하는 API를 통해서 마음대로 데이터를 받아다가 쓸 수 있다.

한줄로 정리하는 내가 생각하는 API

원하는 데이터를 쉽게 가져다 쓸 수 있는 방법

우리가 만드는 건 API

공공데이터
https://www.data.go.kr/index.do
카카오 로그인
https://developers.kakao.com/docs/latest/ko/kakaologin/common

API가 MVC 패턴에서 어떻게 사용되는지?

JSP(Java Server Page)
: 자바가 서버에서 말아주는 페이지
화면인데도 불구하고 자바코드가 엮여있다.
화면까지 결합도 높게 작성되었다.

HTTP 틀
HTTP 틀은 View 따로 Data 따로 나눠서 보내야 한다.
성능을 끌어 올리기 위해서 등장한 개념이 RestAPI

View가 데이터 필요할 때 뒷단을 안 보고 호출/응답 하는게 API

RESTful API란 무엇인가?
우리가 쓴 API가 무슨 데이터를 가져다 주었을까 생각해보자.

API가 RESTful해요?
어느 정도 RESTful해요?
라고 물어볼 수 있다.

RESTful이란 규약이 잘 정해진 API이다.

[회원가입]
사용자(View)
-> "이름, 나이, 주소, 연락처 ..." 주면서 회원가입 시켜줘 '요청'
-> ############## HTTP Request

API(
Controller
-> Model (insert)
-> Controller )
################# HTTP Response
-> View

그림
그림 내용
내가 생각했을때 중요하는 부분

HTTP Request

위 그림은 HTTP Request Message를 나타낸 그림이다.

start line
HTTP Request Message의 시작 부분이다.
start line은 3가지 구조로 구성된다.

HTTP method
Request target
HTTP version

GET /pda.html HTTP/1.1 HTTP Method Request target HTTP version

HTTP method는 Request를 보내는 의도를 나타낸다.

종류
GET: 데이터 요청
POST: 데이터 생성
PUT: 데이터 변경
DELETE: 데이터 삭제

Request target은 HTTP Request가 전송되는 주소이다.

HTTP version은 버전에 따라서 Request 메시지 구조나 데이터가 다를 수 있어서 version을 명시.

headers
request에 대한 추가 정보를 담고 있는 부분이다.

현재 Velog를 작성하는 페이지에서 개발자도구 - 네트워크 페이지에서
작성중인 글을 임시저장 (graphql) 할 때 발생하는 요청 헤더를 확인해보았다.

Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: ko-KR, ko;q~
Access-Control-Request- POST
Origin: https://velog.io
User-Agent: Mozilla/5.0
...

정말 여러 헤더 속성들이 사용되는 것을 확인할 수 있었다.

위 헤더에 대한 내 생각으로는

Accept는 클라이언트가 처리 가능한 미디어 타입들을 종류별로 나열한 것이므로 / 를 보니 왠지 클라이언트가 모든 타입들을 처리할 수 있다 라는 것을 명시한 것 같다.

User-agent 클라이언트 프로그램 정보에 대한 내용이므로 현재 Velog는 Mozilla/5.0, AppleWebKit, Chrome, Safari 등에 대한 브라우저에 맞는 최적의 데이터를 보내줄 수 있다는 의미인 것 같다.

Referer은 바로 직전에 머물렀던 웹 링크 주소를 의미하므로 https://velog.io/ 를 직전에 머물렀다는 것 같다.

Origin은 서버로 Post 요청을 보낼 때 요청이 어느 주소에 시작되었는지 나타내는 값으로 요청이 https://velog.io 주소에서 요청이 시작되었다는 것을 알 수 있다. 그리고 임시 저장 요청을 했을 때, CORS 에러가 발생하지 않았으므로 요청을 받는 주소 역시 https://velog.io라는 것을 알 수 있다.

body
Request가 전송하는 데이터를 담고 있는 부분을 의미한다.

header 부분과 동일하게 임시저장 요청을 하였을 때 body에 어떤 데이터가 저장되는지 확인해보았다.
body에 대한 정보는 작업관리자 - 네트워크 - 페이로드 부분에서 확인할 수 있다.

여기서 알 수 있던 것은
임시저장 요청을 할 경우, 내가 작성한 글들은 variables.body에 text 형식으로 저장되어 요청되는 것을 알 수 있었고, 선택한 태그의 경우 tags라는 배열에 저장되어 전송되는 것을 알 수 있었다. 제목의 경우 title이라는 것에 저장이 되는 것을 알 수 있었다.
위 내용들은 HTML 형식 데이터 이며
전송하는 데이터가 없다면 body가 비어 있기도 하는 것을 알 수 있었다.

Request에서 내가 생각했을 때 중요한 부분
1. Request의 header에 들어가는 필드 값이 많은 것 같다.
각 필드값이 무엇을 의미하는지 공부해보면 좋을 것 같다.
2. start line에서 HTTP version에 대해 명시되어 있는데
아직 어떤 의미인지는 잘 모르겠다. 찾아보고 공부해봐야 할 것 같다.

HTTP Response

status line, headers, body로 구성되어 있다.

status line

HTTP Response의 상태를 간단하게 나타내 준다
[HTTP version][Status Code] [Status Text] 로 구성되어 있다

HTTP/1.1 200 OK

headers

Request의 headers와 동일하다
Response에서만 사용되는 header 값들이 있다

body

모든 Response가 body가 있진 않다
데이터를 전송할 필요가 없을 경우 body가 비어있다

blank line

HTTP 프로토콜 규격을 준수하고, 응답을 구분하는 데 사용된다.

Request에서 내가 생각했을 때 중요한 부분
status code
클라이언트에게 요청이 성공적으로 처리되었는지, 실패했는지 알려주게 되는데 이후에 클라이언트가 다음 단계의 동작을 계속할지 오류를 처리할지 결정할 수 있기 때문에 중요하다고 생각한다.
Request에서 쓰는 header가 있고, Response에서 쓰는 header가 있다.
View는 status 코드(200, 300, 400, 500) 먼저 본다.

"API 설계"
HTTP Request: Method, URL
HTTP Response: Status code + body

HTTP Method(목적) "웹의 목적"
Create: POST
Read : GET
Update: PUT/PATCH
Delete: DELETE

Request 할 때 왜 URL... 중요해요?
버튼, 엔터, ... 웹에서 일어나는 모든 요청은 결국 "URL"

Response status code
http status code
200 / 404 / 500 ... cf. mdn

default port
front: 3000
back: 8080

참고자료
https://developer.mozilla.org/ko/docs/Web/HTTP/Status

쇼핑몰 API

쇼핑몰 메인 페이지 완성 시키려면.. 어떤 API가 필요할까?

API 연습

"상품 전체 조회 API"
Request:
start line - method, url
GET /products.html HTTP/1.1
method(목적) - GET (Read)
url - "http://localhost:8080/products"

header
body - X

Response:
status code - 200
body - 상품 전체 리스트

상품이 여러개 담겨서 올거니까 products

"상품 상세 페이지 - 제목, 가격, 판매자"
상품 상세 페이지 렌더링 할 때 호출할 API
= "상품 개별 조회 API"

Request:
start line - method, url
GET /products/{상품코드} HTTP/1.1
method(목적) - GET (Read)
url - "http://localhost:8080/products/{상품번호}"

header
body - X

Response:
status code: 200
body

상품 1개 객체
{
title:
price:
seller:
}

url은 사람에게 보임. body는 사람에게 안 보임.
중요한 데이터는 body에 담음

상품군, 상품종류
그러나, 페이지에 상품 데이터가 명시되어 있다.
즉, 숨길 필요가 없는 데이터이다.

url
https://www.coupang.com/vp/products/5423439260?vendorItemId=75484504306&sourceType=HOME_GW_PROMOTION&searchId=feed-506059db1d0f487fa3516b5dcabcf43f-gw_promotion&isAddedCart=
아 상품번호는 숨길 필요가 없는 데이터구나
-> URL에 담아도 되겠구나.

왜 product가 아니라 products를 썻을까?
/는 url에서 ~의라는 의미를 갖는다.

vp는 무슨 의미일까?
version production

url 추측
version production
version user
version development
url
https://www.coupang.com/vp/products/5423439260 https://www.coupang.com/vu/products/5423439260 https://www.coupang.com/vd/products/5423439260

장바구니 담기 버튼을 클릭하면.. 어떤 일이 벌어질까?
"장바구니 담기 = 장바구니에 아이템을 저장 API"
Request:
start line - method, url
POST /cartItems HTTP/1.1
method(목적) - POST (Create)
url - "http://localhost:8080/cartItems"

header
body -
{
상품번호: ,
수량: ,
옵션:
}

Response:
status code - 201
body - X

왜 장바구지 담기는 상품번호를 URL에 담으면 안되고, body에
상품번호를 담아야 할까?
A. method가 GET일 때는 body에 어떤 값도 담지 말자.
라는 걸로 시작함.
2014년에 GET에 body를 담는 거를 허용은 하나,
아직 웹 브라우저에 따라서 body를 무시하는 경우가 있다.
누군 되고 누군 안되는 거를 할 필요 없이
body에 담지말고 url에 담자.

내가 개발자라면
1.
url - cartItems/{상품번호}
body - {수량, 옵션}

url - cartItems
body -
{수량, 옵션, 상품번호}

두 번째 방법이 더 편할 것이다.
하나에서 데이터를 다 가져다가 사용하는 것이 편하다.

바로구매를 누르면 로그인 페이지로 넘어가고 결제 페이지로 넘어갈 것 pro이다.

6명이서 할 것
쿠팡 켜고
[구매하기] API 1개, n개

Request:
POST /order HTTP/1.1
url - "http://localhost:8080/order"
body -
{

products: [
 	{
    		productID:
 			quantity:
    }
            
],
address: ,
paymentType:

... 그 외 데이터

}

Response:
status code - 201
body -
{
orderProducts: [
{
productID:
quantity:
}
]

... 그 외 데이터

}

배달의 민족 설계

음식점 전체 조회
음식점 전체 리스트
Request:
POST /order HTTP/1.1
url - "http://localhost:8080/order"
body -
{
```
products: [
 	{
    		productID:
 			quantity:
    }
            
],
address: ,
paymentType:

... 그 외 데이터
```
}

Response:
status code - 201
body -
{
orderProducts: [
{
productID:
quantity:
}
]

... 그 외 데이터

}

음식점 별 음식 전체 조회
음식 리스트
Request:
POST /order HTTP/1.1
url - "http://localhost:8080/order"
body -
{
```
products: [
 	{
    		productID:
 			quantity:
    }
            
],
address: ,
paymentType:

... 그 외 데이터
```
}

Response:
status code - 201
body -
{
orderProducts: [
{
productID:
quantity:
}
]

... 그 외 데이터

}

* 취업 Tip *
1. 차세대란 프로젝트란 무엇일까?
"버전" 유의미한 수정
: ex. 띄어쓰기, 개행 추가 => 무의미
- 1.1 1.2 1.3 2.0 메인버전
- 1.1'.1212' 1.2'.2222' 서브버전

메인버전이 바뀌는 프로젝트를 차세대 프로젝트라고 한다.
기간은 2년~2년 반 정도 걸린다.
DB Dump, Data Insert 등 할 일이 많을 것이다.
성장을 할 수 있는 경험이 될 수도 있다.

2. 면접에서 해볼것
3문장 법칙
면접관에게 대답을 할 때 3문장 내로 끊어서 얘기하자.
사람들이 가장 관심 있어하는 갯수는 3가지이다.
모든 요소를 3가지로 뽑자.
모든 문장은 3가지로 줄여서 말하는 연습을 해보자.

😉 앞으로 이걸 해봐야지

Spring을 배우기 전에 백엔드에 대한 기본 개념들을 습득한 시간이었다.
배운 개념들을 기반으로 Spring을 학습해 봐야겠다.

dev

이전 포스트

HTTP Request/Response

다음 포스트

인터넷 세상 (2024.04.26)

프디아 - 클라우드 기반 백엔드 개발(Spring) 프로그래밍

✋ 수업 목표

🤔 공부한 내용

1. 웹 개요

프로젝트란?

인터넷 vs 웹

웹의 시초 info.cern.ch

HTTP

HTTPS

우리가 만드는 건 API

한줄로 정리하는 내가 생각하는 API

우리가 만드는 건 API

HTTP Request

HTTP Response

쇼핑몰 API

쇼핑몰 메인 페이지 완성 시키려면.. 어떤 API가 필요할까?

배달의 민족 설계

😉 앞으로 이걸 해봐야지

HTTP Request/Response

Spring 시작과 페어프로그래밍 (2024.04.29)

0개의 댓글