[Server] 서버 부트캠프 4주차 수업 - Backend-language & Rest API

Packet

(1)기본 정의

-> 클라이언트와 서버 사이에 오가는 데이터 덩어리

• Header = Meta Data : 데이터를 위한 데이터 
  ex) 학생 목록을 주세요 
  ex) 요청에 대한 상세 사항, 받고자하는 데이터의 타입 지정, 권한 체크 
• Body = Data

(2) 패킷을 주고받는 방법

• HTTP 메소드 : GET, PUT, DELETE, POST, PATCH
  GET - 조회
  DELETE - 삭제
  POST - 생성
  PATCH, PUT - 수정
  PATCH, PUT 차이 - PUT는 전체 정보 수정할 때 사용, PATCH는 일부 정보 수정할 때 사용

 

• Query String
  -> GET에서 원하는 정보 특정하기 위해 사용하는 방법, 필터링할 때 사용
  -> ?로 시작/
  
  ※QueryString과 PathVariable의 차이
     Querystring : 원하는 데이터에 필터링이나 원하는 조건 명시
     PathVariable : 하나의 리소스를 기준으로 할 때 그 리소스 중에 하나를 선택하고자 할때 사용

 

• POST
  -> Body 사용
  -> json, xml 타입이 있음. 요즘은 json이 간편하고 가벼워서 표준으로 쓰는 추세
  -> json : {} 안에  "키" : "데이터" 형테로  나열, 콤마로 데이터 구분, 숫자의 경우 따옴표로 감싸지 않아도 됨

 

• GET과 POST에 대한 오해 : GET이 POST보다 보안상 더 좋지 않다?
  - GET의 경우 요청에 대한 정보가 url에 노출되는 반면에 POST는 body라는 데이터로 보내지기 때문에 url에 노출되지는 않음.
  - 하지만 body 정보는 payload라는 개발자 도구에서 확인이 가능함. url에 숨겨질 뿐 정보가 노출되지 않는 것이 않음
  - 따라서 GET이 POST보다 보안성 좋지 않다는 상식은 잘못된 정보임!
  
  ※그렇다면 보안은 어떻게 챙겨야 할까?
  -> HTTP에 보안 인증서를 받아서 HTTPS로 관리해야 한다.
  -> HTTPS는 데이터 탈주 자체를 많이 방지해 주기도 하고, HTTP는 주고받는 패킷의 내용이 평문 그대로 노출된기 때문에 보안에 취약

 

API (Application Programming Interface)

• 클라이언트는 자신이 원하는 요청에 대해 어떠한 로직으로 동작하는지 알 필요가 없음. 
• 원하는 기능에정대해 정해진 형식으로 요청하는 수단이 API.  interface : 패킷이 어떻게 구성되어 있어야하는지 정의된 형태

 

 

Restful API

• 가장 중요한 개념은 resource를 중심으로 작성하고 사용해야 한다는 것
• HTTP 메소드 4가지는 하고자 하는 행위,API 의 의도를 표현(ex)회원 정보를 생성할건지, 삭제할건지, 조회할건지, 수정할건지)
• uri : 하고자하는 의도의 대상 표현
  ex ) naver.com/uri 
  url 은 도메인과 uri가 합쳐진 형태
  uri는 데이터베이스 테이블 명으로 명사, 복수형태로 표현 ex) users
  
  
• 화면 접근 순서대로가 아닌 리소스 대로 작성하여야 함!!

※ Soft Delete vs Hard Delete

- soft delete : 삭제 '처리'를 하는 것/ put, patch 사용

- hart delete : 실제로 데이터를 삭제하는 것 / delete 사용

 

※삭제 처리를 할때

users/:userId로 하면 수정과 헷갈릴 수 있음

-> users/:userId/status 로 추가 path를 붙이면 된다

 

 

Route,  Controller,  Service/Provider,  DAO/DTO

• route : 외부(클라이언트)에서 오는 요청을 받고 요청에따라 해당 uri에  맞는 컨트롤러로  요청을 매핑(전달)해주는 역할
  ex) 주문 받고 종업원/식당에 전달
• controller :  path variable, query string, body data 등의 데이터를 라우터로부터 전달 받아서 api명세(스펙)기준으로 적절한지 확인 후 service/provider로 전달.
  형식적 유효성 체크
  ex) 주문이 적절한지, 누락된 요청사항이 있는지 체크 후 주방에 전달
• service/provider : 실제 서비스(애플리케이션)의 핵심적인 비즈니스 로직이 실행되는 곳. 데이터베이스와 상호작용. 트랜잭션(논리적으로 데이터가 유효한지 따지는 단계)
  논리적 유효성 체크 - 인스타에서 팔로우를 하려면 팔로우를 하지 않았다는 전제가 있어야 함
  ex) 냉장고에서 재료를 꺼내 손질
• DAO/DTO : 데이터
  DAO :데이터베이스 테이블과 1:1로 매칭되고 있는 형태. users 테이블에 10개의 칼럼이 있다면 users테이블을 관리하는 DAO에는 10개의 칼럼을 관리하는 변수,메소드가 선언됨. 
  DTO : 여러 개의 테이블을 조합해서 주문을 위한 회원정보, 개인정보 수정을 위한 회원정보 등 응답에 대한 DAO
  ex) 완성된 요리를 손님에게 전달

 

 

 

 

 

 

---

Reference

REST API 에 대한 설명(사용법, 특징, 응답상태 코드)

REST API 제대로 알고 사용하기 : NHN Cloud Meetup