[TIL-백엔드] 3주차 Part1. 백엔드와 REST API

반 히·2024년 3월 25일
데브코스프로그래머스프로그래머스 데브코스

데브코스

목록 보기
16/58
post-thumbnail

📌 벡엔드 기초

  • 클라이언트
    • 1) 사용자 → 프론트엔드 (사용자 입장에서는 서버에게 받아온 화면)
    • 2) 프론트엔드 (백엔드 입장에서)
  • 웹 서버의 역할
    • 정적 페이지 : 회사 소개, 회사 연혁, 회사 오시는 길 등등 개개인마다 다른 데이터가 뿌려지는 것이 아니라 누가 봐도 보는 사람들이 같은 데이터를 보게 만든 페이지
    • 동적 페이지 : 개개인에 맞게 데이터가 바뀌는 페이지. 데이터가 계속 바뀌고 추가되는 페이지. 데이터가 추가되거나 삭제되거나 수정이 되거나 하는 (자동으로!!!) 페이지
    • 백엔드에서는 정적 페이지와 동적 페이지를 따로따로 관리를 하긴 함
      • 웹 서버에서는 정적 페이지
      • 웹 어플리케이션 서버에서는 동적 페이지
    • 요즘 백엔드는 정적 페이지 영역보다는 동적 페이지 영역을 신경을 많이 씀
    • 웹 서버 : 프론트엔드의 화면과 정적 페이지
    • 동적 페이지 : 웹 어플리케이션 서버와 데이터베이스의 영향을 받음
  • 웹 어플리케이션 서버와 데이터베이스
    • 백엔드가 신경을 써야 할 파트

📌 API란 (feat. 인터페이스)

  • 백엔드 개발자는 API를 만듦.
  • API (Application Programming Interface)
    • 지하철 도착 어플? 카카오맵, 네이버 지도, 개인 어플
    • 라이브러리에 접근하기 위한 규칙들을 정의한 것
    • 나 이 데이터 좀 줘. 나 이 데이터 연산 좀 해줘.
  • Interface
    • 인터페이스란?
      • 중간에서 양쪽에 있는 친구들을 중재해주고, 매개체가 되어주는 역할
    • GUI : Graphic User Interface
      • = 컴퓨터(프로그램)한테 명령을 내릴 때, 그래픽을 사용해서 명령을 내리는 방식
    • CLI : Command Ling Interface
      • = 명령어 문장("줄") 컴퓨터한테 명령을 내리는 거.

📌 REST API란

  • ✔ API : "데이터 아무렇게나" 주면 되는 거?
    (과거) HTTP 형식을 따르지 않고, 대충 끼워넣어
  • ✔ HTTP 창시자 : 형식 따르면 효율 극대화!!
    "REST API" = HTTP 규약을 잘 따른 API
  • 웹 (=인터넷 망 속에 가상 공간) 개발자
    • = 인터넷을 돌아다니기 위한 규약을 지켜야만!!
    • = HTTP를 지켜야만!!!
  • REST API : HTTP 규약을 잘 따른 API vs RESTful API : HTTP 규약을 매우 매우 잘 따른 API

📌 HTTP에 담아 보내야 하는 것들

  • "인터넷 상에서 공유/전달 하고 싶은 모든 것들은 다 HTTP에 넣어서 보내야 한다!"
    • 위는 프론트엔드 아래는 프론트엔드와 백엔드 그 사이 쯤...

💻 HTTP 프로토콜 템플릿

  • Head - Body
  • Head에는,
    • 1) 통신 상태가 어떤지 알려줘요
      • 예를 들어
        • 200 : 정상이다
        • 404 : 클라이언트가 원하는 걸 못 찾겠다
        • 500 : 서버가 이사아다
      • 우리는 이 숫자들을 HTTP (status) code라고 부름
    • 2) 응답이 어떤 형태인지 적어줘요. 예를 들어 html이다.
  • Body에는
    • 1) 전달해줄 데이터/화면/...
    • 2) 이 데이터 좀 줄래? + "목적" (요청할 때)
      • 전체 상품 보고 싶어 = 전체 상품 리스트 + "조회"
      • 이 상품 등록 해줘 = ___ + "등록"

📌 URL (Uniform Resource Locator)

📌 URL + method 연습 1

📌 API를 어떻게 사용하는가? (화면 실습)

  • 쇼핑몰 메인 페이지 틀 → 전체 상품 조회 API → 전체 상품 데이터를 받고 → 받은 데이터를 페이지에 뿌려줌
  • 상품 상세 페이지틀 → 상품1 개별 조회 API → 데이터를 받아서 → 틀에 맞게 뿌려줌
  • 상품 관리 페이지 → 전체 상품 조회 API → 데이터…
  • 상품 수정 페이지 → 상품 1 개별 조회 API　　　　　　　　　　　//완료 버튼 → 상품 1 수정 API

📌 URL + method 연습 2 "API 설계"

1. 상품 전체 "조회" GET

2. 상품 id 개별 "조회" GET

3. 상품 id 개별 "수정" PUT

  • /products/{id}

cf. 복수형으로 표현하면 좋은 이유

  • 상품"들" 중에 id 값을 가지는 개별 데이터
  • 통일감

📌 HTTP method

💻 HTTP에 담아보내는 나의 목적 = HTTP method

  • 목적을 영어로..? method
  • HTTP = 규약 = 정해둔 용어가 있어요.
  • "외울 필요는 없어요! 대신 적절한 method를 찾아서 사용해주세요."
    • 생성(=등록) : POST
    • 조회 : GET
    • 수정 : PUT(덮어쓰기) / PATCH
    • 삭제 : DELETE
    • HEAD, OPTIONS, CONNECT, TRACE　//데이터 외의 것에 대해서 설정을 하는 메소드, 통신일 때
  • cf. PATCH : 일부 변경? 부분 수정? ex. 마이페이지 : 연락처, 이메일, 집 주소, 이름 (특정 요소만 바꿀 때) ⇒ 부분 수정
profile
반 히
이전 포스트

[TIL] 2주차 Part11. 쇼핑몰 프로젝트 - 백엔드

다음 포스트

[TIL-백엔드] 3주차 Part2. node.js랑 제대로 인사하기

0개의 댓글