코드스테이츠 백엔드 부트캠프 30일차 - [네트워크] HTTP

wish17·2023년 1월 26일

API REST API http postman section_2 네트워크

코드스테이츠 백엔드 부트캠프

목록 보기

26/76

DailyCoding

문자열을 입력받아 연속된 홀수 사이에 Dash("-")를 넣어라.

package CodeStatesAlgorithms;

public class IfOddAddDash {
    public String insertDash(String str) {

        if(str.length()==0) return null;

        String result = str;
        int count = 0;

        for(int i = 0; i < str.length()-1; i++) {
            if(isOdd(str.charAt(i)) && isOdd(str.charAt(i+1)) ){
                result = result.substring(0,i+1+count)+"-"+result.substring(i+1+count);
                count++;
            }
        }
        return result;
    }

    public boolean isOdd(char s){
        int num = s; // char이 int로 알아서 바뀐다.
        if(num%2==0){
            return false;
        }
        return true;

    }
}

//입력
ifOddAddDash.insertDash("243579118239")

//출력
243-5-7-9-1-1823-9

모든 테스트케이스 통과.

int num = s에서 char을 int형 변수에 할당하면 알아서 int로 바뀐다는 것을 알 수 있었다.

	public String insertDash(String str) {
    if(str.length() == 0) {
      return null;
    }
    String result = "" + str.charAt(0); // 문자열로 변환하기 위해 "" 필요

    for(int i = 1; i < str.length(); i++) {
      int preNumber = Character.getNumericValue(str.charAt(i - 1)) % 2;
      int curNumber = Character.getNumericValue(str.charAt(i)) % 2;
      if(preNumber != 0 && curNumber != 0) {
        result = result + "-";
      }
      result = result + str.charAt(i);
    }
    return result;
  }

위와 같이 문자를 하나씩 잘라서 붙일 수도 있다.

Section2 - [네트워크] HTTP

HTTP Messages

HTTP (HyperText Transfer Protocol)
- HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜.
- HTTP 특징 : Stateless(무상태성)
HTTP Messages
- 클라이언트와 서버 사이 데이터 교환 방식
  - 요청(Requests)
  - 응답(Responses)
- HTTP Messages는 여러 줄의 텍스트 정보로 구성
- 구성파일, API, 기타 인터페이스에서 자동 완성
  - 따로 작성할 필요 X
요청/응답 공통 구조
- start line : 항상 첫줄에 위치, 요청의 상태를 나타냄.
  (응답에서는 status line이라 함.)
- HTTP headers : 요청 지정 및 메세지 본문 설명하는 헤더 집합
- empty line : 헤더와 본문을 구분하는 빈 줄
- body : 요청 관련 데이터나 응답 관련 데이터 및 문서 포함. 요청과 응답 유형에 따라 선택적 사용
- start line과 HTTP headers을 묶어 요청이나 응답의 head, payload는 body라 함.
요청 : 클라이언트가 서버에 보내는 메세지
- start line
  1. 수행 작업(GET,PUT,POST 등)이나 방식(HEAD, OPTIONS)를 설명하는 HTTP methods를 나타냄
  2. 요청대상 또는 프로토콜, 포트, 도메인의 절대경로는 요청 컨텍스트에서 작성
  - 요청 형식 HTTP methods
    - origin : ? 와 쿼리 문자열이 붙는 절대경로. POST, GET, HEAD, OPTIONS 등의 메서드 사용
    - absolute : 완전한 URL 형식, 프록시 연결하는 경우 GET메서드와 사용
    - authority : 도메인 이름과 포트번호로 이뤄진 URL의 authority component. HTTP터널 구축 경우 CONNECT와 사용
    - asterisk : OPTIONS 와 함께 * 하나로 서버 전체 표현
  1. HTTP 버전에 따라 HTTP message의 구조 달라짐. 따라서 start line에 버전 함께 입력
- Headers : 헤더이름(대소문자 구분X 문자열), :, 값을 입력. 값은 헤더에 따라 다름
  - General headers : 메세지에 전체 적용 헤더, body통해 전송되는 데이터와 관련X 헤더
  - Request headers : fetch를 통해 가져올 리소스, 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더. User-Agent, Accept-Type, Accept-LAnguage와 같은 헤더는 요청을 구체화. Referer 처럼 컨텍스트 제공, If-None처럼 조건에 따라 제약 추가 가능
  - Representation headers : body에 담긴 리소스의 정보(콘텐츠 길이, MIME타입 등)을 포함하는 헤더
- Body
  - Single-resource bodies(단일-리소스 본문) : 헤더 두개(Content-Type, Content-Length)로 정의된 단일 파일로 구성
  - Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보 가짐. 보통 HTML form과 관련
응답
- Status line
  1. 현재 프로토콜 버전(HTTP/1.1)
  2. 상태 코드 - 요청 결과 (200, 302, 404 등)
  3. 상태 텍스트 - 상태코드에 대한 설명
- Headers
  - General headers : 메세지 전체 적용 헤더, body를 통해 전송되는 데이터와 관련없는 헤더
  - Response header : 위치, 서버 자체 정보(이름, 버전) 와 같이 응답에 대한 부가적인 정보 갖는 헤더, Vary, Accept-Ranges와 같이 상태줄넣기 공간부족했던 추가정보제공
  - Representation headers : body에 담긴 리소스 정보(콘텐츠 길이, MIME타입) 포함 헤더
- Body
  - Single-resource bodies
    - 길이가 알려진 단일 리소스 본문은 두개의 헤더(Content-Type, Content-Length)로 정의
    - 길이를 모르는 단일파일 구성 단일리소스본문은 Transfer-Encoding이 chunked로 설정, 파일은 chuck로 나뉘어 인코딩.
  - Multiple-resource bodies : 서로 다른 정보 담고있는 body

REST API

웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식

API
- HTTP 프로토콜 기반으로 요청응답에 따라 리소스를 주고받기위한 메뉴판 역할

좋은 REST API를 디자인하는 방법

리차드슨의 REST 성숙도 모델

0단계: HTTP 사용
1단계: 개별 리소스와의 통신 준수
2단계: HTTP 메소드 원칙 준수
3단계: HATEOAS 원칙 준수

(cf. 2단계까지만 적용해도 좋은 API 디자인이다.)

0단계: HTTP 사용

단순히 HTTP 프로토콜을 사용하는 단계
(해당 API를 REST API라고 할 수는 없다.)

1단계: 개별 리소스와의 통신 준수

Resource를 도입하는 단계.

모든 요청을 단일 서비스 Endpoint로 보내는 것이 아니라 개별 Resource와 통신
요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환해야 함.

REST API는 웹에서 사용되는 모든 데이터나 자원(Resource)을 HTTP URI로 표현한다. 따라서 모든 자원은 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 하며, 요청하고 받은 자원에 대한 정보를 응답으로 전달해야 한다.

2단계: HTTP 메소드 원칙 준수

CRUD에 맞게 적절한 HTTP 메서드를 사용하는 단계
(CRUD = Create(생성), Read(읽기), Update(갱신), Delete(삭제))

GET - Read
- 서버의 데이터를 변화시키지 않는 요청에 사용해야 함
- cf. body자체를 못씀
POST - Create
- 요청마다 새로운 리소스를 생성
- 요청 데이터 처리, 주로 등록에 사용
PUT - Update
- 요청마다 같은 리소스를 반환 = 멱등(idempotent)
- 교체 용도로 사용
- 리소스를 대체, 없으면 새롭게 생성
PATCH - Update
- 수정의 용도로 사용
- 리소스 부분 변경
Delete - Delete
- 리소스 삭제

이 밖의 메소드가 궁금하면 링크에서 찾아보자.

2단계까지만 적용해도 잘 작성된 API다.

3단계: HATEOAS 원칙 준수

HATEOAS(Hypertext As The Engine Of Application State)라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용하는 단계.

요청은 2단계와 같지만, 응답에 리소스의 URI를 포함한 링크 요소를 삽입하여 작성한다는 차이가 있다.

응답 내에 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 3단계의 중요 포인트

Postman

HTTP 요청을 테스트할 수 있는 API 테스트 도구

Body = JSON 형식으로 보낼 때에는, raw를 선택
(헤더에 Content-Type: application/json 이걸 입력하는 것과 같음)

openweather 날씨 정보 GET하기

원하는 지역 search를 통해 지역 id 를 아래와 같이 알아낸다.

(url 맨 뒤에 있는 7자리 숫자가 city id)

http://api.openweathermap.org/data/2.5/weather?id=1897000&appid={API_KEY}

위에서 구한 id와 api_key를 이용해 완성한 URL을 postman에 입력

{
    "coord": {
        "lon": 127.1378,
        "lat": 37.4386
    },
    "weather": [
        {
            "id": 800,
            "main": "Clear",
            "description": "clear sky",
            "icon": "01d"
        }
    ],
    "base": "stations",
    "main": {
        "temp": 269.76,
        "feels_like": 266.03,
        "temp_min": 268.52,
        "temp_max": 269.76,
        "pressure": 1021,
        "humidity": 28
    },
    "visibility": 10000,
    "wind": {
        "speed": 2.57,
        "deg": 20,
        "gust": 6.17
    },
    "clouds": {
        "all": 0
    },
    "dt": 1674796550,
    "sys": {
        "type": 1,
        "id": 5509,
        "country": "KR",
        "sunrise": 1674772750,
        "sunset": 1674809319
    },
    "timezone": 32400,
    "id": 1897000,
    "name": "Seongnam-si",
    "cod": 200
}