반응형
설명

서버에서 클라이언트로 데이터를 수신하는 방법 (단방향 통신)
WebSocket 의 경우, 서버 <-> 클라이언트 간 양방향 통신을 하지만, SSE 의 경우 단방향 통신을 함!
따라서 간단한 알림 전송 기능 개발등에 적합한 기술

 

구현 예제 
// server-side

// case1) SseEmitter 이용
// https://tecoble.techcourse.co.kr/post/2022-10-11-server-sent-events/ 참고 


// case2) WebFlux 이용 
// ...
@GetMapping(value = "/sse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<String> sse() {
    return Flux.just("Server time: " + LocalDateTime.now())
            .doFinally(signalType -> {
                if (signalType == SignalType.CANCEL || signalType == SignalType.ON_COMPLETE) {
                    log.info("Closing SSE connection");
                }
            });

    ..
}
<!-- client-side --> 
<!-- server-side 의 case2) 방식 대응 --> 

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>SSE TEST</title>
</head>
<body>
<h1>SSE TEST</h1>
<div id="sse-data"></div>
<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
<script>

  const eventSource = new EventSource("{server-side주소}/sse");
  eventSource.onmessage = event => {
     $("#sse-data").append(event.data); // 이부분을 토스트 팝업 형태로 표현하면 됨!
  };

  eventSource.onerror = error => {
    console.error("SSE error:", error);
    eventSource.close();
  };
</script>
</body>
</html>
반응형

'개발 > etc' 카테고리의 다른 글

Vault  (1) 2023.02.07
헥사고날 아키텍처 (Hexagonal Architecture)  (2) 2022.09.25
JWT (JSON WEB TOKEN)  (0) 2021.12.22
Rest API  (0) 2021.06.02
HTTP관련 (https, spdy, ajax, websocket)  (0) 2018.12.09
반응형

✎ Vault 

API 을 사용하여 민감정보를 관리하는 시스템.

✱ 민감정보
비밀번호, 토큰, 인증서 등의 암호화 해야하는 어떠한 것들

https://www.vaultproject.io/ 에서 개발함.

 

 Vault 사용 이유

프로젝트 내에 보안적인 요소를 고려해야 하는 값(계정 및 패스워드 = 민감정보 등)들을 HTTP API 통신을 이용하여 외부(=git 저장소 등)에 노출시키지 않은 상태로 사용할 수 있기 때문에 보안에 효율적임.

 

 

 간단하게 스프링부트 프로젝트 에서 사용해본 Vault

1. Vault 설치 및 실행 확인

$ brew install vault # vault 설치
$ vault server --dev --dev-root-token-id="00000000-0000-0000-0000-000000000000" # vault 서버 실행

https://www.vaultproject.io/docs/commands/server 에 자세한 설명이 있다.

대충 이렇게 뜸
http://localhost:8200 으로 접속했을 시 나오는 화면


⁉️ 만약 Get "https://127.0.0.1:8200/v1/sys/internal/ui/mounts/secret/application/db": http: server gave HTTP response to HTTPS client 이러한 에러가 발생하였을 경우
↓↓ 아래내용 실행 (터미널)

$ export VAULT_ADDR='http://localhost:8200'

 

2. key/vaule 생성 및 확인

$ vault kv put secret/application username=mungmang password=12345 # key, vaule 생성

Key                Value
---                -----
created_time       2022-01-08T15:46:25.89734Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1
$ vault kv get secret/application # path 으로 key, vaule 조회 

======= Metadata =======
Key                Value
---                -----
created_time       2022-01-08T15:46:25.89734Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

====== Data ======
Key         Value
---         -----
password    12345
username    mungmang

https://learn.hashicorp.com/collections/vault/getting-started 에 vault 사용 방법에 대해 자세히 설명해준다.

 

3. SpringBoot project 에 vault 연동여부 적용

// build.gradle 파일에 아래의 정보 추가

ext {
    ...
    set('springCloudVersion', "2021.0.1-SNAPSHOT")
}

dependencies {
	...
	implementation 'org.springframework.cloud:spring-cloud-starter-vault-config'
}
    

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
    }
}
// application.yml에 아래의 내용 추가
spring:
  config:
    import: vault:// 
  cloud:
    vault:
      uri: http://localhost:8200
      token: 00000000-0000-0000-0000-000000000000
      kv:
        backend: secret
        default-context: application #secret 이후의 경로

참고로 Spring Cloude Vault 3.0 및 Spring Boot 2.4 이상에선 bootstrap.yml, bootstrap.properties 가 더이상 사용되지 않는다고함. 그리고  Spring Boot Config Data 접근방식을 사용하려면 spring: config: import에 Vault 시스템을 바인딩 하기 위한 속성 설정이 필요함. (Spring Boot 의 Config Data API
아님, application.yml에 spring:cloud:bootstrap:enabled: true or pom.xml or build.gradle 파일에 spring-cloud-starter-bootstrap import을 하여 bootstrap.yml 을 활성화를 할 수 있음.

https://docs.spring.io/spring-cloud-vault/docs/current/reference/html/#client-side-usage 에 자세한 설명이 있다.

 

// config 패키지 생성후 아래의 클래스 생성 

@Getter
@Configuration
public class VaultData {

    @Value("${username}")
    private String username;

    @Value("${password}")
    private String password;
}
// 확인

@Slf4j
@SpringBootApplication
public class HelloApplication {

    public static void main(String[] args) {

        ConfigurableApplicationContext context = SpringApplication.run(HelloApplication.class, args);

        // vault 테스트 --
        VaultData vaultData = context.getBean(VaultData.class);
        log.info("username:{}", vaultData.getUsername());
        log.info("password:{}", vaultData.getPassword());
    }
}

 

 

 

end ~

반응형

'개발 > etc' 카테고리의 다른 글

SSE (Server Sent Event)  (1) 2023.08.20
헥사고날 아키텍처 (Hexagonal Architecture)  (2) 2022.09.25
JWT (JSON WEB TOKEN)  (0) 2021.12.22
Rest API  (0) 2021.06.02
HTTP관련 (https, spdy, ajax, websocket)  (0) 2018.12.09
반응형
설명

포트 앤 어댑터 아키텍처을 이용
 외부영역 & 내부영역 을 나눠 고수준의 내부 영역이 외부 영역에 의존하지 않도록 하는것이다!
‣ 유지보수, 유연성, 확장성에 좋음.
‣ 복잡할수록 빛을 발하지만, 단순하다면 경우 이렇게까지 구성할 필요는 없음!

🔸 외부영역
• 비지니스 처리 결과 리턴 (REST API 발행)
• 인바운드 어댑터, 아웃바운드 어댑터로 구성

🔸 내부영역
• 순수 비지니스 로직 구성
• 외부영역과 연계되는 포트를 가지고 있음
• 인바운드 포트, 아웃바운드 포트로 구성
• POJO 존재


 아웃바운드 어댑터가 아웃바운드 포트에 의존해서 구현됨
 어플리케이션이나 어댑터가 변경 되어도 도메인은 영향을 받지않음
 클린 아키텍처와도 유사
‣ SOLID의 단일책임원칙(Single Reason to Change Principle, SRP), 의존성역전원칙(Dependency Inversion Principle, DIP) 을 이용

※ 포트 앤 어댑터 아키텍처
인터페이스나 기반 요소의 변경에 영향을 받지 않는 핵심 코드를 만들고 이를 견고하게 관리하는것이 목표
외부영역과 내부영역을 분리함
영역의 사이 input, ouput 전달은 포트(=인터페이스) 을 통해서만 함.
※ 단일책임원칙(Single Reason to Change Principle, SRP)
하나의 컴포넌트는 오로지 한 가지 일만 해야하고, 그것을 올바르게 수행해야함! 
= 컴포넌트 변경 이유는 오직 하나뿐이여야함!!!

※ 의존성역전원칙(Dependency Inversion Principle, DIP) 
코드상의 어떤 의존성이든 그 방향을 바꿀 수 있다.

 

구조

https://engineering-skcc.github.io/microservice%20inner%20achitecture/inner-architecture-2/

 

https://github.com/wikibook/clean-architecture


🌱 
인바운드 포트
▪︎ 인바운드 어댑터가 호출(사용함)

🌱 아웃바운드 포트
▪︎ 아웃바운드 어댑터가 아웃바운드 포트에 의존하여 구현
(=아웃바운드 포트가 아웃바운드 어댑터 구현체 호출)

🌱 인바운드 어댑터
▪︎ 외부요청 처리 (API 요청/응답 결과)
▪︎ 아웃바운드 포트 인터페이스를 가져다가 사용하여 어댑터를 생성.
▪︎ 스프링 MVC 컨트롤러, 커맨드 핸들러, 이벤트 메세지 구독 핸들러 등.

🌱 아웃바운드 어댑터
▪︎ 내부 비지니스 영역과 외부 서비스간 데이터 교환
▪︎ 데이터 엑세스 처리 (DAO), 이벤트 메세지 발생, 외부 서비스 호출 등 

 

 

이를 사용하계된 계기 (계층형 아키텍처의 단점)

‣ 계층형 아키텍처는 데이터베이스 주도 설계를 유도함. (도메인에 의존이 아닌 데이터베이스에 의존) - 비지니스 관점으로는 별로임
‣ ORM 프레임워크의 경우 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받음.
‣ 영속성 코드가 도메인코드에 녹아들면 마음대로 바꾸기가 쉽지 않게 됨.
‣ 웹 계층 테스트시 도메인 및 영속성 범위까지 모킹해야함. 시간소요가 많아짐.
‣ 그외에도 테스트가 어렵고 동시작업이 어려움.
유지보수 쉬운! 소프트웨어를 만들필요성이 있다.

 

 

 

 


참고

- 링크: https://engineering.linecorp.com/ko/blog/port-and-adapter-architecture/

- 링크: https://velog.io/@youngmin-mo/hexagonalarchitecture

- 인프런강의: https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard

- 책: 만들면서 배우는 클린 아키텍처

반응형

'개발 > etc' 카테고리의 다른 글

SSE (Server Sent Event)  (1) 2023.08.20
Vault  (1) 2023.02.07
JWT (JSON WEB TOKEN)  (0) 2021.12.22
Rest API  (0) 2021.06.02
HTTP관련 (https, spdy, ajax, websocket)  (0) 2018.12.09
반응형
json web token
설명

JSON 객체를 사용하여 토큰 자체에 정보들을 저장하고 있는 웹토큰.
claims을 안전하게 전달하는 표준.
HMAC 알고리즘 사용 하거나, RSA or ECDSA를 사용하는 공개 / 개인키 쌍을 사용하여 서명이 가능함.
권한 부여 및 정보교환시점에서 사용.

✳︎ claims ?
JWT 의 PAYLOAD 부분을 구성하고 교환되는 정보 집합.

 

토큰생김새
eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJ0ZXN0IiwiYXV0aCI6IlJPTEVfVVNFUiIsImV4cCI6MTY0MDI2NjczOX0.A5bzyF4jkKVmdDzboK8_qsPbDh3qGO3v2lgcSp5K41CxmSgyDZlKxBfcZNiZ754S_IDhFOPO7m18bsBqhZgBMw

위와 같은 형태로 생겼으며, https://jwt.io/ 사이트에서 토큰 정보를 확인할 수 있다.

 

구성방식

HEADER, PAYLOAD, SIGNITURE 으로 구성된다. 
이 세부분은 Base64url 인코딩을 사용하여 별도로 인코딩되며 JWT 생성을 위하 점(.)을 사용하여 연결된다. 

var token = base64UrlEncoding(HEADER) + '.' + base64UrlEncoding(PAYLOAD) + '.' + base64UrlEncoding(SIGNITURE);

↓↓↓↓

var token = 
eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJ0ZXN0IiwiYXV0aCI6IlJPTEVfVVNFUiIsImV4cCI6MTY0MDI2NjczOX0.A5bzyF4jkKVmdDzboK8_qsPbDh3qGO3v2lgcSp5K41CxmSgyDZlKxBfcZNiZ754S_IDhFOPO7m18bsBqhZgBMw

 

각 구성 설명은 아래와 같다.

HEADER signiture 정보를 해싱하기 위한 알고리즘 정보들이 담겨있는곳.
HMAC, SHA256 or RSA 와 같은 서명 알고리즘 두 부분으로 구성됨.
PAYLOAD 서버, 클라이언트가 주고 받는 시스템에서 실제로 사용될 정보에 대한 내용이 담겨있음.
PAYLOAD claims 은 3가지 유형이 존재

- registered claims: 필수는 아니지만 상호 운용을 위해 미리 정의된 클레임(RFC 7519) 집합 (iss, exp, sub, aud..)

- public claims: jwt 을 사용하는 사람들이 마음대로 정의. 충돌 방지 위해 네임스페이스를 포함하는 URL로 정의 필요

- private claims: 사용에 동의하고 등록된 클레임이나 공개 클레임이 아닌 당사자간의 정보를 공유하기 위해 생성된 맞춤 클레임
SIGNITURE 토큰의 유효성 검증을 위한 문자열. 이 문자열로 유효한 토큰인지 확인함.
메세지가 변경되었는지 확인하는데 사용.

 

 

동작방식

jwt 토큰 인증 방식 기준으로 그려본것이다. (oauth2의 허가는 생략)

accessToken, refreshToken이 jwt 으로 구성되어있다.

 

장점과 단점
  • 장점
    중앙의 인증서버, 데이터 스토어에 대한 의존성이 없고, 시스템 수평확장에 유리하다.

  • 단점
    PAYLOAD 정보가 많아지면 네트워크 사용량이 증가함.
    토큰이 클라이언트에 저장되기에 서버에서 클라이언트의 토큰을 조작할 수 있다.

 

 


참조

https://jwt.io/introduction

 

JWT.IO

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

jwt.io

https://ko.wikipedia.org/wiki/JSON_%EC%9B%B9_%ED%86%A0%ED%81%B0

 

JSON 웹 토큰 - 위키백과, 우리 모두의 백과사전

JSON 웹 토큰상태인터넷 표준최초 출판일2010년 12월 28일 (2010-12-28)마지막 버전RFC 75192015년 5월조직IETF약어JWT JSON 웹 토큰(JSON Web Token, JWT, "jot”[1])은 선택적 서명 및 선택적 암호화를 사용하여 데

ko.wikipedia.org

https://velog.io/@kshired/Express%EC%97%90%EC%84%9C-JWT%EB%A1%9C-%EC%9D%B8%EC%A6%9D%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0-Access-Token%EA%B3%BC-Refresh-Token

 

Express에서 JWT로 인증시스템 구현하기 ( Access Token과 Refresh Token )

Express에서 jwt를 이용하여 access token으로만 인증을 하는 글은 많이 있는데, refresh token까지 구현한 자료는 그렇게 많지않아 이 글을 쓰게 되었습니다.이 글은 구현에 치중되어 있어, JWT의 자세한

velog.io

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-jwt/dashboard

 

[무료] Spring Boot JWT Tutorial - 인프런 | 강의

Spring Boot, Spring Security, JWT를 이용한 튜토리얼을 통해 인증과 인가에 대한 기초 지식을 쉽고 빠르게 학습할 수 있습니다., [사진] 본 강의는 Spring Boot, Spring Security를 이용해서 JWT 인증과 인가를 쉽

www.inflearn.com

https://techdocs.akamai.com/api-gateway/docs/json-web-token-jwt-val#jwt-claims

 

JSON web token (JWT) validation

JSON web token is an open standard (RFC 7519) that defines a compact and self-contained method for securely transmitting JSON-encoded information between parties. With <<COMPANY_NICKNAME>>, you can use JWTs to quickly identify and authorize API consumers w

techdocs.akamai.com

 

반응형

'개발 > etc' 카테고리의 다른 글

SSE (Server Sent Event)  (1) 2023.08.20
Vault  (1) 2023.02.07
헥사고날 아키텍처 (Hexagonal Architecture)  (2) 2022.09.25
Rest API  (0) 2021.06.02
HTTP관련 (https, spdy, ajax, websocket)  (0) 2018.12.09
반응형
REST (Representational State Transfer)
설명

자원을 표현(Representational)으로 구분하여 해당 자원의 상태(State)를 주고 받는(Transfer)다.
HTTP URI(Uniform Resource Identifier)을 통해 자원(Resource)을 명시하고, Http Method(GET, POST, PUT, DELETE)을 통해 자원에 대한 CRUD Operation을 적용

✱ URI (Uniform Resource Identifier)
인터넷 자원을 나타내는 유일한 주소
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
 - URN: 자원의 이름 (식별자)
 - URL: 자원의 위치 

 

구성요소

1. 자원 (Resource)
‣ Http URI (ex. /users/:userId)

2. 행위 (Method)
‣ GET, POST, PUT, DELETE,
‣ HEAD (요청 header 정보만 응답),
‣ PATCH (PUT과 다르고, 자원의 일부만 수정하고자 할때 사용),
‣ OPTION (현재 End-point가 제공 가능한 API method를 응답)

3. 표현 (Representation of Resource)
  Client(브라우저)가 자원의 상태에 대한 조작을 요청(Request)하면 서버는 이에 적절한 응답(Response)을 보낸다.
  JSON, XML, TEXT, RSS 등 여러 형태로 표현

 

REST API 특징

1. 클라이언트/서버
 아키텍처를 단순화 시키고 작은단위로 분리함으로써
클라이언트 - 서버 각 파트가 독립적으로 개선될 수 있도록 한다. 


2. 상태없음
 클라이언트의 상태가 서버에 저장되어서는 안된다.

3. 레이어드 아키텍처 (Layered Architecture)
 클라이언트 - 서버 연결 사이의 중간 서버가 존재하는 경우 (클라이언트 - 중간서버 - 서버),
중간서버(게이트웨이, 방화벽, 프록시 etc)는 로드밸런싱 혹은 공유 캐시 기능을 제공함으로써
시스템 규모 확장성을 향상시키는데 유용

4. 캐시 (Cache)
 클라이언트 응답을 캐싱할 수 있어야 함. 캐싱함으로서 서버에 부하 최소화

5. 코드 온 디맨드(Code on demand)
 요청이 오면 코드를 준다는 의미로 특정 시점에 서버가 특정 기능을 수행하는 스크립트 또는
플러그인을
클라이언트에 전달해서 해당 기능을 동작하도록 하는것. (자바스크립트, 플래시 etc)

6. 통합 인터페이스
 일관적인 인터페이스로 분리 되어야 함.

 

REST 인터페이스 규칙

1. 리소스 식별
 요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. (URI)

2. 표현을 통한 리소스 처리
 다양한 콘텐츠 유형으로 표현 가능 (JSON, XML, HTML ..)

3. 자기 묘사 메세지
 Http header 에 메타 데이터 정보를 추가해서 실제 데이터와는 관련 없지만
데이터에 대한 설명을 나타내는 정보를 담을 수 있음.

4. 어플리케이션의 상태에 대한 하이퍼미디어(HATEOAS, Hypermedia As The Engine Of Application State)
 REST API 개발할 때에 단순 데이터만 전달하지 않고, 링크 정보까지 포함하여 전달 (하이퍼 텍스트 링크)
 리소스 상태가 전이되는 경우에 변경되는 정보를 제공하고자 함.
(등록 요청 후, 변경 된 정보를 좀 더 자세히 알고자 할때 하이퍼 링크도 같이 제공)
    

 

REST API 
설명

REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스

 

RESTful의 목적

API 이용자가 해당 API 으로 데이터를 얻고, 특정 기능을 파악할 수 있도록 하는 것

 

리소스 원형

도큐먼트 (document)
 객체 인스턴스나 데이터베이스 레코드와 유사한 개념

컬렉션 (collection)
 서버에서 관리하는 디렉터리 리소스 

스토어 (store)
 클라이언트에서 관리하는 리소스 저장소
 API 클라이언트가 리소스를 등록/수정/삭제에 관여

컨트롤러 (controller)
 절차적인 개념을 모델화 한 것

 

✰ REST API 디자인을 위한 규칙

추상적인 것 보단, 구체적인 것이 좋다.
ex) /animals -> /pigs

동사를 사용하지 않는다. (명사를 사용)
method 를 동사 대용으로 사용.

단수보단, 복수를 사용하는 것을 권장한다.
ex) /thing  ->  /things or /things/{id}

슬래시(/) 을 사용하여 계층관계를 표시해야 한다.
리소스간 연관관계는 /리소스명/리소스ID/관계가 있는 다른 리소스명 으로 표현한다.

ex) GET /users/{userid}/devices (소유자가 가지고있는 디바이스 목록?)

URL 마지막에 슬래시(/) 을 포함하지 않는다.
슬래시를 포함한다면, 슬래시 다음에 식별자가 와야하는데 오지 않음으로 혼동을 줄 여지가 있음.

URI의 가독성을 높히려면 하이픈(-)을 사용해야 한다.

URI에 밑줄(_)을 사용해선 안된다.
보기가 어려움. 가독성

URI 경로에는 소문자를 사용해야 한다.

파일 확장자는 사용하지 않는다.

 


참고

https://www.redhat.com/ko/topics/api/what-is-a-rest-api

(책) 스프링 부트로 배우는 자바 웹 개발

 

REST API(RESTful API, 레스트풀 API)란 - 서버, 구현, 사용법

REST API(RESTful API)란 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻합니다. api 서버, rest api 구현 및 사용법을 설명합니다.

www.redhat.com

https://nsinc.tistory.com/192

 

URL vs URI vs URN

인터넷을 사용하면서 많이 만나게 되는 URI, URL, URN의 개념에 대해서 정리해보고자 합니다. URI, URL, URN은 기술적인 구분이 아닌 개념적인 차이라고 볼 수 있으므로 참고 바랍니다. URI vs URL vs URN ?

nsinc.tistory.com

https://spoqa.github.io/2013/06/11/more-restful-interface.html

 

RESTful API를 설계하기 위한 디자인 팁

RESTful api를 설계하기 위한 개념들을 추가적으로 알아보고 유용하게 쓰일만한 HTTP헤더와 상태코드를 살펴봅니다.

spoqa.github.io

https://dzone.com/articles/7-rules-for-rest-api-uri-design-1

 

7 Rules for REST API URI Design - DZone Integration

URIs, or Uniform Resource Identifiers, should be designed to be readable and clearly communicate the API resource model. These rules will help you succeed.

dzone.com

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

 

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

https://www.slideshare.net/nexusz99/rest-api-48600643

 

REST API 디자인 개요

REST API가 무엇이고 그것을 어떻게 디자인해야하는지에 대해 나름대로 정리를 해보았습니다.

www.slideshare.net

https://zsgg.tistory.com/entry/REST-API-%EB%94%94%EC%9E%90%EC%9D%B8-%EA%B7%9C%EC%B9%99

 

REST API 디자인 규칙

여전히 우리는 다음과 같은 질문들에 대한 답을 찾아야 한다. URI 경로path 세그먼트는 언제 복수로 써야 하는가? 리소스의 상태를 업데이트하려면, 어떤 메서드를 사용해야 하는가? CRUD12가 아닌

zsgg.tistory.com

https://sanghaklee.tistory.com/57

 

RESTful API 설계 가이드

1. RESTful API 설계 가이드 본 문서는 REST API를 좀 더 RESTful 하게 설계하도록 가이드할 목적으로 만들어졌다. 따라서, 기본적인 REST API 개념 설명은 아래의 링크로 대신한다. REST API 제대로 알고 사용

sanghaklee.tistory.com

https://meetup.toast.com/posts/92

 

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

REST API 제대로 알고 사용하기

meetup.toast.com

 

반응형

'개발 > etc' 카테고리의 다른 글

SSE (Server Sent Event)  (1) 2023.08.20
Vault  (1) 2023.02.07
헥사고날 아키텍처 (Hexagonal Architecture)  (2) 2022.09.25
JWT (JSON WEB TOKEN)  (0) 2021.12.22
HTTP관련 (https, spdy, ajax, websocket)  (0) 2018.12.09
반응형

1. HTTP가 무엇?

    • HTTP는 클라이언트 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다.  (?프로토콜 : 통신규약)

예를 들면, 

클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지나 그림 정보를 요청하면, 

서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 

 

이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다.

HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.

 

클라이언트에서 서버 에다가 요청(request)을 하고 응답(response)을 받기 위해선 다음과 같은 과정을 거친다.

  • TCP/IP는 인터넷 프로토콜 관련 집합을 총칭한다. (TCP, IP, FTP, SFTP, HTTP..)
  • HTTP는 클라이언트와 서버간의 통신을 한다.
  • HTTP는 버전이 존재한다.
  • 요청(request)응답(response)을 교환하여 성립한다.
- 요청메세지메소드(=명령),  URI,  프로토콜버전(=http 버전),  요청헤더필드 등을 만들어서 전달.
- 응답메세지에는 요청결과에대한 상태코드값(=202, 404..),  프로토콜버전(=http 버전),  바디(=소스본체 html..)..등을 만들어서 전달.
 
  • HTTP는 상태를 유지하지 않는다.
    • 프로토콜은 과거기억을 못한다(=요청 응답 처리 후를 기억 못함). 그래서 대안으로 쿠키를 사용하는 것이다.
 
  • URI로 리소스를 지정. 이를 이용하여 인터넷상의 어떤 리소스를 호출 가능.
  • 메소드를 사용해서 지시한다.
    • GET, POST, PUT, HEAD, DELETE, OPTION, TRACE, CONNECT, LINK, UNLINK...
  • 지속연결
    • TCP를 종료하지 않아 한번에 많은양의 데이터를 보낼 수 있도록 함.
  • 파이프라인화
    • 클라이언트가 요청 후, 응답 안기다리고 바로 다른 요청을 보낼 수 있음.
    • 이미지 10장이 한번에 나오는 예
 
2. HTTP 단점
    • HTTP를 사용한 요청이나 응답은 자기자신을 암호화하지 않는다. (도청 당할 가능성)
    • 통신 상대를 확인하지 않는다. (누군가가 위장 할 수 있다)
    • 그래서 이러한 이유로 HTTPS 사용하는것.
      • HTTPS는 새로운 애플리케이션 프로토콜은 아니며,
      • HTTP 통신 소켓부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security) 프로토콜로 대체하고 있음.
      • HTTPS는 http+ssl+tcp/ip 인셈
 
      • 병목현상이 있음
      • 서버의 정보가 갱신 되었는지 확인하기 위해서는 매번 클라이언트가 서버에게 확인요청을 해야함. (통신양이 많아질것임)
      • 1개의 연결로 1개의 요청만 보낼 수 있음
      • 무조건 클라이언트가 서버에서 요청을 보낼수 있음. 응답만 받는것은 안됨.

 

3. WebSocket
    • 양방향 통신을 한다.
    • 클라이언트에서 서버 에다가 웹소켓 연결 요청을 하여 접속확립이 되면 연결을 끊지 않고, 어느쪽에서든지 송신을 할 수 있는 상황이 됨.
    • 서버 푸시기능이있음.
    • 통신량이 줄어듬(한번 연결하면 접속을 유지하기 때문에 오버헤드가 적어짐)
    • 핸드쉐이크

 

- 참고 

 

반응형

'개발 > etc' 카테고리의 다른 글

SSE (Server Sent Event)  (1) 2023.08.20
Vault  (1) 2023.02.07
헥사고날 아키텍처 (Hexagonal Architecture)  (2) 2022.09.25
JWT (JSON WEB TOKEN)  (0) 2021.12.22
Rest API  (0) 2021.06.02

+ Recent posts