멋쟁이사자처럼(명지대) 수업 1주차

Crmal·2022년 5월 26일
0

1주차

목표

  • 클라이언트와 서버의 차이를 아는 것
  • http를 들어보는 것
  • https가 더 좋다는 것을 아는 것
  • API에 대해 들어보는 것
  • REST라는게 있구나
  • RESTFUL이라는 말도 있구나

웹이란 무엇인가?

월드 와이드 웹(world wide web)의 줄임말로 첫 글자를 따서 WWW라고 부르기도 합니다.

인터넷 상에서의 정보저장과 사용환경에 대한 연구를 통해 웹에서는 어떠한 종류의 컴퓨터를 사용하여도 한 가지 종류의 표준 사용자 환경으로 조작이 가능하도록 하였습니다.

💡 **인터넷에서 운영되는 서비스 중 하나**이고 많은 정보가 서로 얽혀있다.

웹의 동작

웹에 연결된 컴퓨터는 클라이언트 와 서버 라고 합니다.
그림과 같은 방식으로 서로 통신을 하는데
클라이언트, 즉 브라우저는 서버에 request, 요청을 보내고
서버는 요청에 대한 response, 응답을 다시 클라이언트에게 돌려줍니다.

이 둘 사이의 통신 규약을 HTTP라고 합니다.

HTTP

HTTP (Hypertext Transfer Protocol)란?

  • 서버와 클라이언트가 인터넷 상에서 데이터를 주고받기 위한 프로토콜.
  • 프로토콜이란?
    • 컴퓨터나 통신 장비 사이에서 메시지를 주고 받기 위해 설계된 일련의 규칙 체계

💡 나는 이렇게 줄 테니 넌 이렇게 받고 난 너가 준거 그렇게 받을께

HTTP의 구조

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. 

HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

  • Stateless란? 상태가 없다라는 말은 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리가 된다는 말입니다. 좀 더 쉽게 말해서 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 말이죠. 서버는 세션과 같은 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 처리 및 서버의 부하를 줄일 수 있는 성능 상의 이점이 생깁니다.

HTTP 작동 방식

  • 서버/클라이언트 모델을 따른다.
  • 연결을 끊어버리기 때문에, 클라이언트 이전 상황을 알 수 없다.
  1. 클라이언트가 서버에게 요청함
  2. 서버가 클라이언트로부터 요청을 받음
  3. 서버가 클라이언트에게 응답을 보냄

하지만 HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이었기 때문에, HTTP로 비밀번호나 주민등록번호 등을 주고 받으면 제 3자가 정보를 조회할 수 있었다.

이러한 문제를 해결하기 위해 HTTPS가 등장하게 되었다.

HTTPS

HTTPS 란?

💡 HTTPS는 하이퍼 텍스트 전송 프로토콜 **보안**(Hypertext Transfer Protocol **Secure**)의 약자입니다.

일반 HTTP 프로토콜의 문제점서버와 브라우저 사이에 전송되는 정보가 암호화되지 않는다는 것이었다.

이 말은 즉, 데이터가 쉽게 도난 당할 수 있다는 것이었습니다. HTTPS 프로토콜은 SSL(보안 인증서)을 사용함으로써 이 문제를 해결했습니다.


제 3자가 중간에 가로채도 암호화 되어있어 볼 수 없습니다.

HTTP vs HTTPS 차이’는 바로 SSL 인증서입니다.

사실 HTTPS는 쉽게 말해서 HTTP 프로토콜에 보안 기능을 추가한 것이라고 말할 수 있는데요. 보안 기능은 생각보다 매우 중요합니다. 특히 신용카드 정보나 비밀번호 등 사용자들의 민감한 정보들을 다루는 웹 사이트에서 라면 더욱 그렇죠.

SSL은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을 때 이것이 도난 당하는 것을 막아줍니다.

TLS은 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공하고 있습니다.

또 다른 장점

HTTPS로 전환하게 되면 검색엔진 최적화(SEO)에 있어서도 큰 혜택을 볼 수 있다.

→ 사이트가 더 많이 노출되고 유입이 많아지면서 사용자들이 증가한다

Request 와 Response

  • Request : 웹 브라우저(클라이언트)를 통해 서버에 요청하는것
  • Response : 서버에서 웹 브라우저(클라이언트)에 응답하는 것

HTTP 메서드

대표적으로 GET, POST, PUT, DELETE 메소드가 있습니다


method의미
GETRead데이터 조회
POSTCreate요청 데이터 처리, 주로 데이터 등록에 사용
PUTUpdate데이터 수정(전체 수정)
DELETEDelete데이터 삭제
PATCHUpdate데이터 수정(부분 수정)

이 밖에 더 자세한 메서드들을 알고싶다면 : http method

그렇다면 어디다 보낼 것이냐?

URL을 이용한다!

URL(Uniform Resource Locators)은 개발자가 아니더라도 이미 우리에게 익숙한 용어입니다. 서버에 자원을 요청하기 위해 입력하는 영문 주소죠. 아무래도 숫자로 되어 있는 IP 주소보다는 훨씬 기억하기 쉽기 때문에 사용하는 것 같습니다.

URL 구조는 아래와 같습니다.

HTTP 응답코드


2xx - 성공

200번대의 상태 코드는 대부분 성공을 의미합니다.

  • 200 : GET 요청에 대한 성공
  • 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
  • 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
  • 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환

3xx - 리다이렉션

300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서
새 URL로 리다이렉트를 유도하는 경우입니다.

  • 301 : Moved Permanently, 요청한 자원이 새 URL에 존재
  • 303 : See Other, 요청한 자원이 임시 주소에 존재
  • 304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인

4xx - 클라이언트 에러

400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우입니다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생합니다. 가장 익숙한 상태 코드는 404 코드입니다. 요청한 자원이 서버에 없다는 의미죠.

  • 400 : Bad Request, 잘못된 요청
  • 401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
  • 403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지
  • 405 : Method Not Allowed, 허용되지 않은 요청 메서드
  • 409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌

5xx - 서버 에러

500번대 상태 코드는 서버 쪽에서 오류가 난 경우입니다.

  • 501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
  • 503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우

REST, REST API, RESTFUL

API

  • 정의 : Application Programming Interface의 줄임말로 쉽게 이야기하면 규칙들의 집합입니다.
  • 역할
    • 점원의 역할이다

    • 손님의 주문을 (클라이언트) → 점원이 받아 → 주방으로 전달 (서버)

    • 주방의 음식을(서버) → 점원이 받아 → 손님에게 전달(클라이언트)

언제쓰나요?

→ 여러분들은 프로젝트를 진행할 때 사용하게 될거에요

→ 서버 파트에서 API 서버를 만들어주면

→ 프론트 파트에서 해당 API를 요청하고 응답값(데이터)를 받아 화면에 보여줄겁니다

참고자료 : https://maily.so/grabnews/posts/b2341a

REST

Representational State Transfer의 줄임말로

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용
하는 것을 의미한다.

→ 어느 자원을 어떻게 할 것인가?

  • 자원 : 해당 소프트웨어가 관리하는 모든 것
    • 문서, 그림, 데이터, 해당 소프트웨어 자체 등
  • 자원의 표현 : 그 자원을 표현하기 위한 이름
    • DB의 학생 정보가 자원일 때, ‘students’를 자원의 표현으로 정한다.

REST API

💡 REST를 기반으로 API 서비스를 구현한 것

REST API 설계 규칙

  1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다
    1. http://restapi.example.com/houses/apartments
    2. https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
  2. 마지막엔 / 를 포함하지 않는다
  3. 확장자는 포함하지 않는다
  4. 소문자를 쓰자
  5. 하이픈(-)을 쓰면 가독성이 좋아진다

예시

이미지 참고

  1. API 서버란?

REST가 필요한 이유

  • ‘애플리케이션 분리 및 통합’
  • ‘다양한 클라이언트의 등장’
  • 최근의 서버 프로그램은 다양한 브라우저와 모바일 디바이스에서도 통신을 할 수 있어야 한다.
  • 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었다.

REST특징

  • Server-Client(서버-클라이언트 구조)
    • 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
    • REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
    • Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
      서로 간 의존성이 줄어든다.
  • Stateless(무상태)
    • HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
    • Client의 context를 Server에 저장하지 않는다.
      • 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.
    • Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
      • 각 API 서버는 Client의 요청만을 단순 처리한다.
      • 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
      • 물론 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용한다.
      • Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.
  • Cacheable(캐시 처리 가능)
    • 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
      • 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
      • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
    • 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
    • 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.
  • Layered System(계층화)
    • Client는 REST API Server만 호출한다.
    • REST Server는 다중 계층으로 구성될 수 있다.
      • API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.

RESTFUL

💡 REST의 원리를 따르면 restful하다 고 표현한다

목적

  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

왜 Restful하게 만들어야하나요?

  • 모두가 이해하기 쉬우니까..!

Restful하지 못한 경우

  • 모든 기능을 POST로 처리하는 경우
  • url에 resource, id 외의 정보가 들어가는 경우(/students/updateName)

참고자료

https://velog.io/@ellyheetov/REST-API
[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog (gmlwjd9405.github.io)

요약

  • http보단 https가 좋다
  • https를 이용하면 웹사이트 점수를 더 받아 더 많이 노출될 수 있다.
  • 서버에 요청하면 request, 클라이언트에 응답하면 response이다.
  • API를 가지고 클라이언트와 서버가 요청/응답을 처리한다
  • API도 만드는 규칙이 있다.
  • API는 RESTFUL하게 만들어야 한다.

0개의 댓글