뚝딱뚝딱

REST : 웹(HTTP)의 장점을 활용한 아키텍쳐

1. REST (REpresentational State Transfer) 기본

• REST의 요소

• method

** idempotent : 한 번 수행하냐, 여러 번 수행했을 때 결과가 같나?

• Resource
  ✔ http://myweb/users와 같은 URI
  ✔ 모든 것을 Resource (명사)로 표현하고, 세부 Resource에는 id를 붙임
  
  
• Message
  ✔ 메시지 포맷이 존재
  : JSON, XML 과 같은 형태가 있음 (최근에는 JSON 을 씀)

HTTP POST, http://myweb/users/
{
	"users" : {
		"name" : "terry"
	}
}

• REST 특징

• Uniform Interface (일관된 인터페이스)
  
  • HTTP 표준을 기반으로 하며, 특정 언어나 기술에 종속되지 않음.
  • 예를 들어, REST API가 HTTP와 JSON을 사용하여 정의되었다면, 어떤 플랫폼이든 해당 API에 접근 가능.
• Self-Descriptive Messages (자기 서술적 메시지)
  
  • API 메시지 자체만으로도 그 의미를 이해할 수 있도록 설계해야 함.
  • 메시지를 보고도 어떤 리소스에 어떤 동작을 수행하는지 직관적으로 이해할 수 있어야 함.
• HATEOAS (Hypermedia As The Engine Of Application State)
  
  • 응답에는 현재의 상태를 나타내는 하이퍼링크가 포함되어야 함.
  • 클라이언트는 이 링크를 통해 다음에 수행 가능한 작업을 이해하고 진행할 수 있음.
• Statelessness (무상태성)
  
  • 각각의 요청은 독립적이며, 서버는 클라이언트의 상태를 저장하지 않음.
  • 이로써 서버는 간단해지고, 확장성이 높아짐.
• Resource 지향 아키텍처 (ROA)
  
  • 자원(리소스)을 중심으로 하는 아키텍처
  • 각 리소스는 고유한 URI(Uniform Resource Identifier)를 가지며, 명사 형태로 정의됨.
• Client-Server Architecture (클라이언트-서버 아키텍처)
  
  • 시스템을 클라이언트와 서버로 분리함으로써 각각의 역할을 명확하게.
• Cache Ability (캐시 사용 가능)
  
  • 응답은 캐싱될 수 있어서, 동일한 요청에 대한 반복적인 처리를 최소화
• Layered System (계층화 구조)
  
  • 시스템은 계층화될 수 있어서, 각 계층은 독립적으로 구현
  
  
• Code On Demand (선택적 코드 전송)
  
  • 서버로부터 클라이언트가 실행 가능한 코드를 전송할 수 있습니다. 이는 선택 사항이며, 일반적으로는 사용되지 않음
  
  

=> REST는 자원을 중심으로 하며, 간단하고 일관된 인터페이스를 통해 클라이언트와 서버 간의 통신을 단순화하고 효율적으로 만들기 위한 웹 아키텍처

***참고
https://gyoogle.dev/blog/web-knowledge/REST%20API.html

HTTP Request Methods란?
클라이언트가 웹서버에게 요청하는 목적 및 그 종류를 알리는 수단을 말한다.

1. GET
   URL(URI) 형식으로 서버 측에 리소스를 요청한다.
   리소스(데이터)를 받기 위함
2. HEAD
   GET과 유사하지만, HEAD는 실제 문서 요청이 아닌 문서에 대한 정보 요청이다.
   즉, Response 메세지를 받았을 때, Body는 비어있고, Header 정보만 들어있다.
   메세지 헤더 정보를 받기 위함
   
   
3. POST
   클라이언트에서 서버로 어떤 정보를 제출하기 위해 사용한다.
   Request 데이터를 HTTP Body에 담아 웹 서버로 전송한다.
   내용 및 파일 전송을 하기 위함
   
   
4. PUT
   POST와 유사하나, 기존 데이터를 갱신할 때 사용한다.
   리소스(데이터)를 갱신하기 위함
   
   
5. DELETE
   웹 서버측에 요청한 리소스를 삭제할 때 사용한다.
   (실제로 클라이언트에서 서버 자원을 삭제하도록 하진 않아 비활성화로 구성한다.)
   리소스(데이터)를 삭제하기 위함
   
   
6. CONNECT
   보통 Proxy를 통해 SSL 통신을 하고자할 때 사용한다.
   클라이언트와 서버 사이의 중간 경유를 위함
   
   
7. OPTIONS
   웹 서버 측에서 지원하고 있는 메소드가 무엇인지 알기 위해 사용한다.
   서버 측 제공 메소드에 대한 질의를 하기 위함
   
   
8. TRACE
   웹 서버로부터 받은 내용을 확인하기 위해 loop-back 테스트를 할 때 사용한다.
   Request 리소스가 수신되는 경로를 보기 위함
   
   
9. PATCH
   PUT과 유사하나, 모든 데이터를 갱신하는 것이 아닌 리소스의 일부분만 수정할 때 쓰인다.
   리소스(데이터)의 일부분만 갱신하기 위함

***참고
https://gyoogle.dev/blog/web-knowledge/HTTP%20Request%20Methods.html

개발자 톡방에서 GitHub Copilot chat에 대해 반응이 뜨겁길래 뭔가 하고 찾아봤다

대충 알아보니, vscode나 intelliJ 같은 개발환경에 설치하면, 이 Github Copilot chat이 내가 쓴 코드를 읽고 분석해서 더 최적화된 코드로 알려준다거나, 오류 등을 파악해서 바로 해결해주는 등의 마법사 같은 역할을 하는 것 같다.

지금까지 코드 상에 오류가 발생하면, 코드를 긁어서 CHAT GPT한테 물어보고, "오류를 수정해줘"라고 했을 것이다.

간단한 프로젝트면 그나마 나을지 모르지만, 큰 프로젝트나 코드의 길이, 여러 클래스들끼리 이리저리 얽혀있다면, 솔직히 그 많은 코드를 긁어서 완벽히 해결해달라고 하기엔 무리였다.

이제 CHAT GPT가 내장된 copilot chat이 내 프로젝트 코드들의 관계를 알아서 다 읽어보고 분석한 후, 오류가 발생한 부분에 대해서 척척 알려줄 것이다.

브라우저를 열었다 닫았다 할 귀찮음도 사라지고, 더이상 코드를 긁어 물어보지 않아도 되니 정말 좋은 서비스인것 같다.

다른 사람의 후기를 보니, 자신은 프론트엔드 개발자인데, copilot chat이 백엔드를 알아서 짜주고, 심지어는 db연결까지 다 해주었다고 한다. 풀스택이 가능해진 것이다.

이젠 백/프론트엔드 개발자라 하더라도 무리없이 보충해 풀스택으로 개발하는게 수월해질 것 같다.

다음은 공식 문서를 바탕으로 정리한 Github Copilot chat에 대한 부가 설명이다.

💡 GitHub Copilot Chat의 주요 기능!!

1. 코드 자동 완성

• 이 기능은 마치 나의 생각을 읽어내듯, 다음 코드 라인을 예측하고 제안해 주는 것이다.

2. 버그 수정

• 이 기능은 GitHub Copiolt Chat이 문제를 식별하고, 해결방안을 제시해 준다.
• 더이상 오류에 머리를 싸매지 않아도 된다!

💡 GitHub Copilot Chat의 장점!!

• 내 코드를 전체적으로 분석하고, 내 코딩 스타일에 맞추어서 코드를 제안해준다
• 설치과정이 몇분으로 간단하다
• 복잡한 코드, 어려운 알고리즘 문제 모두 copilot chat이 척척 도와줄것이다!!
• 코드를 작성하는 속도, 문제 해결 능력 향상 

다가오는 12월 중순 정식 출시 된다고 하네요!! 

💡 문제)
USED_GOODS_BOARD와 USED_GOODS_USER 테이블에서 완료된 중고 거래의 총금액이 70만 원 이상인 사람의 회원 ID, 닉네임, 총거래금액을 조회하는 SQL문을 작성해주세요. 결과는 총거래금액을 기준으로 오름차순 정렬해주세요.

1. 회원 ID, 닉네임, 총거래금액을 조회
   SELECT B.USER_ID, B.NICKNAME, SUM(A.PRICE) AS TOTAL_SALES
   문제에서 주어진 쿼리 결과대로 총거래금액의 출력 시 이름을 TOTAL_SALES로 바꾸어준다.
   
   
2. USED_GOODS_BOARD와 USED_GOODS_USER 테이블에서
   테이블 두개가 연결되어야 함을 알 수 있다. 테이블을 보면 USER_ID에 대해서 중복된 것을 알 수 있다 (컬럼이름은 각 테이블에서 다르지만, 결국은 USER의 아이디를 가리키고 있음)
   따라서 두 테이블을 유저 아이디에 대한 조건으로 INNER JOIN시켜야 한다.
   그래야 각 상품 목록에 대해서 유저의 정보를 함께 출력하는 테이블을 얻을 수 있기 때문이다.
   FROM USED_GOODS_BOARD A JOIN USED_GOODS_USER B ON A.WRITER_ID=B.USER_ID
   
   
3. 완료된 중고 거래의
   위의 2번까지를 통해 각 상품에 대한 유저 정보까지 합친 테이블을 얻었으니, 이제 그 중에서도 완료된 거래에 대해서만 추려야 한다.
   그러러면 WHERE 절을 이용해서 STATUS가 DONE인 것만을 가져올 수 있다.
   WHERE A.STATUS="DONE"
   
   
4. 총금액이 70만 원 이상인 사람의
   위의 과정까지는 각 상품에 대해서 개별적으로 조회되기 때문에, 한 사람의 전체 거래 내역을 고려하기 위해서는 사람의 단위로 GROUP을 지어야 한다.
   따라서 GROUP BY 절을 통해 USER_ID 별로 그룹화 시킨다.
   그러면 거래가 완료된 상품의 거래 주인의 아이디, 이름, 총거래금액이 출력되는데, 이 중에서도 조건에서 총거래금액이 70만원 이상인 사람의 것만 출력하라고 되어 있다.
   그러므로 GROUP BY 절에 HAVING을 추가해서 그 그룹 중 총거래금액이 70만원이상인 것만 출력하도록 해준다.
   GROUP BY B.USER_ID HAVING TOTAL_SALES>=700000
   
   
5. 결과는 총거래금액을 기준으로 오름차순 정렬해주세요.
   (나는 이 단계를 빼먹고 채점 결과가 자꾸 틀렸다고 떠서 시간을 낭비했다. 꼭 정렬 조건을 확인하도록 하자)
   이제 조건에 만족하는 결과는 다 출력했다.
   마지막 조건인 정렬을 해준다.
   ORDER BY절을 통해 해줄 수 있다.
   ORDER BY TOTAL_SALES;

위 다섯 단계를 거치면서 하나하나씩 접근하면 매우 쉬운 문제이다!

조인, WHERE절, GROUP BY절, ORDER BY절이 다 쓰인 문제라서, 순서를 한번 정리하고 넘어가자

SELECT > FROM > JOIN-ON > WHERE > GROUP BY - HAVING > ORDER BY