브렌쏭의 Veritas_Garage

HTTP Request / Response 본문

[Project_만들다]/[Project_자아내다]

HTTP Request / Response

브렌쏭 2022. 3. 16. 14:56
HyperTexT Protocol

즉, 프로토콜이다. HTML 이 HyperText Markup Language니까, 그 하이퍼텍스트를 전송하는 약속이라고 하면 되겠다.

서버와 클라이언트 사이에서 하이퍼텍스트 문서를 '주고' '받으니' 당연히 2개의 방식으로 되어있는 구조이다.

1. 누가 주는 쪽이며, 받는 쪽인가?

모든것은 클라이언트를 기준으로 한다. 어차피 클라이언트 측 화면을 보기위해 이 모든걸 만든거니까.

따라서 클라이언트가 요청하는 것이 Request, 또한 클라이언트가 응답받는 것이 Response다.

2. HTTPS는?

HTTP에게 진화의 돌(TLS)을 붙여 진화시킨 형태이다. 보안 업그레이드 버젼. 요즘엔 이게 기본이다.

3. 일단 REQUEST.

한영키 전환하기 귀찮으니까 리퀘스트나 요청이라고 쓰겠다.

리퀘스트는 클라이언트가 서버에게 정중하게 "야 담배있냐?" 하고 묻는 과정이다.

이때 클라이언트는, 늘상 서버와 연결되어있진 않으며, 서로 단답형으로 지 할말만 하고 끊는 상남자식 프로토콜을 가진다.

요청에는 몇가지 종류가 있다. 설명은 읽기 싫으면 넘기고 종류만 봐라.

  • GET: 야 보여줘
  • HEAD: 걔 이름이 뭔데
  • POST: 야 적어봐
  • PATCH: 미안 잘못 말함 ㅈㅅ 다시 말해줌
  • PUT: 야 넣어둬
  • DELETE:  야 버려
  • TRACE: 거 내가 뭐라고 했었지?
  • CONNECT: 야 지금 내가 폰 잃어버려서 빌려서 전화함
  • OPTIONS: 야 너 뭐 할줄 아냐

 

 

이렇게 있는데... 일단 크게 나누면 서버가 가진 내용물에 영향을 주는 요청서버 내용물은 건들지 않는 요청이 있다.

REST 개념에서는 CRUD라고 4가지로 나누는데, 그냥 2개로 나누고 각각 외워도 된다.

그리고 중요한건 진하게 썼다. 일단 REST기준으로 작성

3-1. 서버에게 영향을 준다 (Mutation in graphql)

서버 내용물이 변하는 요청이다. 회원가입을 해서 내 데이터를 저장시킨다던가, 블로그에 글을 싸거나.. 카카오톡 프사를 바꾼다던지..수많은 요청이 있다. 아래 설명은 읽어봐라.

  • POST: 클라이언트가 서버에서 처리할 수 있는 자료를 보낸다.
  • PATCH: 클라이언트가 서버에게 지정한 URL의 데이터를 부분적으로 수정할 것을 요청한다.
  • PUT: 클라이언트가 서버에게 지정한 URL에 지정한 데이터를 저장할 것을 요청한다.
  • DELETE: 클라이언트가 서버에게 지정한 URL의 정보를 제거할 것을 요청한다.

기능적인 만큼 종류도 많다. 대부분 P로 시작한다 사용자의 입력에 반응해서 내용물이 바뀌는 것이다. 검색도 서버에 영향을 준다. 검색어를 넣으니까. 

3-2. 서버에 영향이 없다 (Query in graphql)

그냥 보여달라는 요청이다. 아 그냥 좀 보여달라고

  • GET: 클라이언트가 서버에게 URL에 해당하는 자료의 전송을 요청한다.
  • HEAD: GET 요청으로 반환될 데이터 중 헤더 부분에 해당하는 데이터만 요청한다.
  • TRACE: 클라이언트가 서버에게 송신한 요청의 내용을 반환해 줄 것을 요청한다.
  • CONNECT: 클라이언트가 특정 종류의 프록시 서버에게 연결을 요청한다.
  • OPTIONS: 해당 URL에서 지원하는 요청 메세지의 목록을 요청한다.

주소창에 네이버 적으면 네이버 보여주는 것과 같다. 남들이 보낸 메세지나 프사를 보는 것도 그렇다. 보기만 하는 것이다. 

4. 응답하라 RESPONSE

서버가 하는 일이다. 예의바르게 양식에 맞춰 요청이 들어오면 그에 맞게 대답하는 것이다. "ㄴㄴ 돗대임"

그리고 연결을 끊는다. 그것이 약속이니까.

끄덕
그것이 프로토콜이라는 것이니까.

5. 구체적으로 어떻게 하나

예전에는 XML을 이용해서 XHRs 라는 것을 했다지만, 고대 유물이다.

아무리 못해도 Fetch API를 사용하거나 AXIOS 같은 것을 쓴다.

일단 fetch의 경우, ES6 Promise문법을 지원하기 때문에 간편 편리 너무조아 하다.

fetch ("apiUrl")
	.then((response) => {
		console.log("resoveld", response);
		return respose.json()
})
	.then(data => {
		console.log(data);
})
	.catch((error) => {
		console.log("wrong", error);
})

.then 을 쓰니까 여러번 리퀘스트를 할 수도 있다.

fetch ("apiUrl")
	.then((response) => {
		console.log("resoveld", response);
		return respose.json()
})
	.then (data => {
		console.log(data);
		return fetch("apiUrl2");
})
	.then (res2 => {
		console.log("Second Requst resolved");
		return res2.json()
})
	.then (data2 => {
		console.log(data2);
})
	.catch ((error) => {
		console.log("wrong", error);
})

물론 .try .catch로 감싸서 오류 핸들링은 해줘라 

더 나아가 async function을 써도 좋다. 

const dataFromAPI = async () => {
	try {
		const response = await fetch("apiUrl");
		const data = await response.json();
		console.log(data);

		const res2 = await fetch("apiUrl2");
		const data2 = await res2.json();
		console.log(data2);
	} catch (error) {
		console.log ("error..", error);
	}
}

dataFromAPI();

그래도 불편했는지, 누군가는 AXIOS를 만들었다. 누군지는 몰라도 만드는게 더 귀찮았을덧.

내부적으로는 fetch를 사용하는데, 겉으로 보기엔 더 간편하게 작성할 수 있도록 해주는 jQuery같은 것이다.

axios.get("apiUrl")
.then((response)=>{
	console.log(response);
})
.catch((e) => {
	console.log(e);
})

확연히 짧긴핟.

async를 사용핻 넘 짧앗

const getState = async (id) => {
	try{
		const res = await axios.get(`apiUrl${id}`);
		console.log(res.data);
	} catch (e){
		console.log(e)
	}
}

getState(id);

헤더에서 보통 무슨 요청인지 명확하게 해주는데, AXIOS는 다음과 같다.

const getState = async (id) => {
	try{
		const config = { headers : { Accept : application/json }}
		const res = await axios.get(`apiUrl${id}`, config );
		console.log(res.data);
	} catch (e){
		console.log(e)
	}
}

getState(id);

물론 난 Udemy에서 들은 강좌의 필기를 정리했을 뿐이고, 앞으로 내가 배우는건 다를지도 모른다. 틀린건 없다. 걱정마라.

6. 추가적으로

가끔 404 오류를 보기도 하는데, 그건 니 잘못이다. 왜냐하면 그 번호에는 다 뜻이 있기 때문이다.

  • 200~ : good
  • 300~ : redirection
  • 400~ : client side wrong
  • 500~ : server side errors

그렇지? 역시 니가 잘못했지?

7. 그리고 RESTful Routes

이건 상호 연결을 하는 방식 중 하나인데, 논문이 있다. 

클라이언트와 서버 간 통신의 약속방식, 양식, 패턴 기타 등등을 소상히 적어서 Representational State Transfer 라는 개념에 맞게 만든 것이라고 한다.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

 

Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)

proxy CERN Proxy, Netscape Proxy, Gauntlet

www.ics.uci.edu

이만 줄인다. 

Comments