[백엔드스터디]5일차 학습일지

오늘은 미니프로젝트 작업결과물을 발표하는 시간을 가졌다. 

 

 

소스피드백결과 - 

1. 어디에 get을쓰고 어디에 post를 써야하는지 구분해서 활용할것 

 

2. db로 저장하지않아도 되는것부분까지 db저장하여 활용할필요는 없다 

 

 

🤨 : Get을 쓸 때는 언제고, Post는 또 언제 쓸까?

정확히는 이 두 method가 어디가 어떻게 다른지가 궁금했습니다.

실제 많은 개발자들은 GET과 POST를 용도구분없이 혼용해서 사용했고 Delete같은 곳에도 GET방식을 편의대로 이용한 것입니다.

그래서 알아봤더니, 정말 예상외로 너무 많은 분들이 이와 관련된 글들을 작성해주셨더라고요.
제 궁금증들을 해결하는데 다들 큰 도움을 주셨습니다.
정말 감사합니다.🙇🏻‍♂️

많은 자료들과 글이 있음에도 불구하고 이 글을 쓰는 이유는, 글을 작성함을 통해 좀 더 정확하게 구분하기 위해서입니다.
글을 작성함을 통해, 생각들을 다시 한 번 정리하고 피드백도 받기 위함이죠.😉

 

그래서 차이가 뭐라고?🤬

너무 신나서 떠들었더니 서론이 너무 길었네요. 본론으로 넘어가서
먼저, 이 둘의 차이점보다는 이 둘에 더 정확히 아는게 더 좋을 듯 합니다.
Post와 Get, 각각의 특징과 역할들을 봐보도록 하죠.

Get

GET method는 클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용되는 메서드입니다.

좀 더 쉽게 말하자면, 데이터를 읽거나(Read), 검색(Retrieve)할 때에 사용되는 method라고 할 수 있겠네요.

GET은 요청을 전송할 때 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링(QueryString) 이라고 부릅니다.

e.g.) www.example-url.com/resources?name1=송유현&name2=곽철용

위 예는 앞서 말한 쿼리스트링을 포함한 URL입니다. 파라미터인 name1과 name2를 통해 값을 전달받을 수 있습니다.
만약, 요청 파라미터가 여러 개이면 &로 연결합니다.

그리고 GET 요청은 오로지 데이터를 읽을 때만 사용되고 수정할 때는 사용하지 않습니다.
따라서 이런 이유로 사용하면 안전하다고 간주되죠. 즉, 데이터의 변형의 위험없이 사용할 수 있다는 뜻입니다.

GET 요청에 대한 기타 참고 사항

• GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있습니다.
• 파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때 GET 요청을 사용해서는 안 됩니다.
• GET 요청은 브라우저 기록에 남습니다.
• GET 요청을 북마크에 추가할 수 있습니다.
• GET 요청에는 데이터 길이에 대한 제한이 있습니다.
• Get 요청은 성공시, 200(Ok) HTTP 응답 코드를 XML, JSON뿐만 아니라 여러 데이터(html, txt등..), 여러 형식의 데이터와 함께 반환합니다.
• GET 요청은 idempotent합니다.

지금 당장은 idempotent가 뭔 말인지 몰라도 괜찮습니다.
이따가 Post와 Get의 차이점에서 자세히 다뤄보도록 하죠.

 

Post

POSTmethod는 리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용됩니다.

GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송합니다.
그리고 그 Body의 타입은 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시 따라 결정 된다.
(POST로 요청을 보낼 때는 해야 합니다.)

HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있습니다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있는 이유도 이 때문입니다.

이처럼 POST는 데이터가 Body로 전송되고, 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬의 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 합니다.

Post 요청에 대한 기타 참고 사항

• POST 요청은 캐시되지 않습니다.
• POST 요청은 브라우저 기록에 남아 있지 않습니다.
• POST 요청을 북마크에 추가할 수 없습니다.
• POST 요청에는 데이터 길이에 대한 제한이 없습니다.
• Post 요청 중 자원 생성은 201(Created) HTTP 응답 코드를 반환합니다.
• Post 요청은 idempotent하지 않습니다.
  
  

Get과 Post의 차이점

위 사진은 Get과 Post의 리소스 전달 방식의 차이를 표현한 사진입니다.

GETPOST

캐시	⭕️	❌
브라우저 기록	⭕️	❌
북마크 추가	⭕️	❌
데이터 길이 제한	⭕️	❌
HTTP 응답 코드	200(Ok)	201(Created)
언제 주로 사용하는가?	리소스 요청	리소스 생성
리소스 전달 방식	쿼리스트링	HTTP Body
idempotent	⭕️	❌

 

idempotent란??

아까부터 idempotent란 단어가 자꾸 보이는데,
대체 이 단어가 뭐길래 이렇게 쓰는지 한 번 알아나봅시다.

idempotent는 멱등법칙(冪等法則) 또는 멱등성(冪等性)이란 뜻으로, 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.
출처 : 위키백과

너무 어렵게 보지 않으셔도 됩니다. 우리가 집중해야할 부분은 딱 한 줄이기 때문입니다.
👉연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질👈

즉, 멱등이라는 것은 동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나야 합니다.

GET은 Idempotent, POST는 Non-idempotent하게 설계되었습니다.

여기서 GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다는 것을 의미합니다. 이에 따라 GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent하기 때문에 주로 조회를 할 때에 사용해야합니다.

예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하게 됩니다.

반대로 POST는 Non-idempotent하기 때문에 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있습니다.
이에 따라 POST는 서버의 상태나 데이터를 변경시킬 때 사용됩니다.

게시글을 쓰면 서버에 게시글이 저장이 되고, 게시글을 삭제하면 해당 데이터가 없어지는 등 POST로 요청을 하게 되면 서버의 무언가는 변경되도록 사용됩니다. 이처럼 POST는 생성, 수정, 삭제에 사용할 수 있지만, 생성에는 POST, 수정은 PUT 또는 PATCH, 삭제는 DELETE 가 더 용도에 맞는 메소드라고 할 수 있습니다.