👨‍🏭
개발 저장소
  • 📔HTTP
    • HTTP
      • 1. HTTP의 이해
      • 2. HTTP Client
      • 3. HTTP Server
      • 4. Java HTTP Server
  • 📔REST API
    • REST API
      • 1. REST API
      • 2. URI & MIME type
      • 3. Collection Pattern
  • 📔DTO & JSON & CORS
    • DTO & JSON & CORS
      • 1. DTO(Data Transfer Object)
      • 2. 직렬화(Serialization)
      • 3. JSON
      • 4. Jackson ObjectMapper
      • 5. CORS
  • 📔DataBase
    • DataBase
      • DB (Database)
      • DBMS (Database Management System)
      • SQL(Structured Query Language)
      • 데이터 모델(Data Model)
      • JDBC(Java Database Connectivity)
      • JdbcTemplate
  • 📔Spring
    • Spring Web MVC
    • Separation of Concerns
    • 객체지향 (OOP)
    • 객체지향의 5가지 원칙(SOILD)
    • Layered Architecture
  • 📔JPA
    • jpa
      • ORM(Object-Relational Mapping)
      • JPA(Jakarta Persistence API)
      • Hibernate
      • Embedable
      • RelationShop Mapping
        • N + 1 문제
        • DDD Aggregate
        • CascadeType.ALL
        • orphanRemoval
        • Event Sourcing
        • @OneToMany와 @JoinColumn
      • Spring Data JPA
        • JPA Repository와 DDD의 Repository
        • Spring AOP
  • 📔DDD(Domain Driven Design)
    • Domain-Driven Design (DDD)
    • Strategic Design
    • Tactical Design
Powered by GitBook
On this page
  • API(Application Programming Interface)
  • 정보은닉(Information Hiding)과 캡슐화(Encapsulation)
  • Architecture와 Architecture Style의 차이
  • REST(7가지 제약 조건)
  1. REST API
  2. REST API

1. REST API

API(Application Programming Interface)

API (Application Programming Interface)는 일반적으로 3개의 계층으로 구성된 3-Tier 구조로 설계됩니다. 이 구조는 각 계층이 서로 분리되어 독립적으로 작동하고, 유연하고 확장성이 높은 시스템을 만들 수 있도록 합니다.

  1. Presentation Tier (표현 계층): 사용자 인터페이스를 담당하는 계층으로, 웹 브라우저나 앱과 같은 클라이언트에서 사용자와 상호작용하는 역할을 합니다. 이 계층에서는 사용자 입력을 받아들이고, 결과를 표시하기 위해 API를 호출합니다.

  2. Application Tier (응용 계층): 비즈니스 로직을 처리하는 계층으로, API의 핵심 로직을 담당합니다. 이 계층에서는 데이터를 처리하고, 비즈니스 규칙을 적용하여 결과를 생성합니다.

  3. Data Tier (데이터 계층): 데이터를 저장하고 관리하는 계층으로, 데이터베이스와 같은 데이터 저장소가 위치합니다. 이 계층에서는 데이터를 저장, 조회, 수정 및 삭제하는 작업을 수행합니다.

API는 이렇게 3-Tier 구조로 설계됨으로써, 각 계층이 분리되어 있기 때문에 유지보수, 확장성, 보안성이 향상되며, 클라이언트와 서버 사이의 상호작용이 용이해집니다.

GoF의 디자인 패턴 1.6

GoF(Gang of Four, 네명의 저자들)는 "Design Patterns: Elements of Reusable Object-Oriented Software"라는 책에서 소개한 디자인 패턴 23가지를 제안하였습니다.

  • 추후 업데이트

Interface

Communication: Interface는 두 개 이상의 시스템 또는 구성 요소 간의 통신을 가능하게 합니다. Interface는 다른 구성 요소가 요청할 수 있는 작업 및 응답할 수 있는 작업을 정의하여 통신을 지원합니다.

Specification: Interface는 다른 시스템 또는 구성 요소가 이해할 수 있는 표준화된 형식으로 작업 및 데이터를 명시적으로 정의합니다. Interface는 또한 다른 구성 요소에서 제공해야 하는 기능, 속성 또는 동작에 대한 규격을 제공합니다.

Information Hiding (Principle): Interface는 구성 요소의 내부 구현을 외부로부터 숨기는 정보 은닉 원칙을 준수합니다. Interface는 구성 요소의 내부 세부 정보를 외부로 노출하지 않고, 구성 요소가 외부에 노출해야 하는 기능만을 정의합니다.

Encapsulation (Technique): Interface는 구성 요소의 구현과 외부 코드의 결합도를 낮추기 위한 캡슐화 기술을 사용합니다. Interface는 외부 코드가 구성 요소의 내부 구현에 직접 접근하는 것을 방지하고, 대신 Interface를 통해 외부와 상호 작용하도록 유도합니다.

Implementation: Interface는 구성 요소의 구현과 외부 코드의 결합도를 낮추는데 도움을 주지만, 이를 구현하는 코드는 여전히 필요합니다. 구현 코드는 Interface가 정의한 작업을 구현하고, 구성 요소의 내부 구현을 캡슐화하며, Interface를 통해 외부와 상호 작용합니다.

Web API

Web API(Web Application Programming Interface)는 웹 응용 프로그램과 상호 작용할 수 있도록 공개된 프로그래밍 인터페이스를 말합니다. 웹 API는 웹 개발자가 다른 애플리케이션, 서비스 또는 플랫폼과 상호 작용할 수 있는 방법을 제공하며, 데이터 교환 및 응용 프로그램 간 상호 운용성을 촉진합니다.

웹 API는 일반적으로 HTTP 프로토콜을 사용하여 데이터를 전송하며, JSON 또는 XML과 같은 데이터 형식을 사용하여 데이터를 인코딩합니다. 이러한 데이터 형식은 데이터를 구조화하고 인간이 읽을 수 있는 형식으로 변환하여 응용 프로그램에서 쉽게 처리할 수 있도록 합니다.

웹 API는 대부분의 경우 REST(Representational State Transfer) 아키텍처 스타일을 따르며, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 CRUD(Create, Read, Update, Delete) 작업을 수행합니다. REST 아키텍처는 클라이언트와 서버 사이의 자원을 표현하고 전송하는 데 사용되는 일반적인 웹 아키텍처 스타일입니다.

웹 API는 많은 온라인 서비스와 애플리케이션에서 사용됩니다. 예를 들어, 페이스북 API를 사용하면 개발자는 페이스북의 사용자 데이터를 읽거나 쓸 수 있습니다. 또한 Google Maps API를 사용하면 개발자는 지도 및 위치 정보를 제공할 수 있습니다. 이러한 웹 API는 다양한 애플리케이션에서 데이터 교환 및 상호 운용성을 향상시키는 데 사용됩니다.

정보은닉(Information Hiding)과 캡슐화(Encapsulation)

정보은닉(Information Hiding)과 캡슐화(Encapsulation)는 객체 지향 프로그래밍의 중요한 개념 중 하나입니다. 둘 다 객체의 내부 구현을 외부에서 보이지 않게 하여 객체를 안전하고 보호할 수 있도록 합니다. 하지만 둘은 약간의 차이가 있습니다.

정보은닉(Information Hiding)은 객체의 내부 데이터와 메서드를 외부에서 직접 접근하지 못하도록 보호하는 것입니다. 즉, 객체의 내부 구현을 외부에서 볼 수 없도록 숨기는 것을 말합니다. 이렇게 하면 객체의 상태를 변경하거나 메서드를 호출하는 등 객체에 대한 변경이나 접근을 외부에서 직접적으로 할 수 없으므로 객체의 안전성을 보장할 수 있습니다.

반면에 캡슐화(Encapsulation)은 객체의 내부 데이터와 메서드를 하나로 묶어서 객체라는 하나의 캡슐에 넣는 것을 말합니다. 이렇게 하면 객체가 외부로부터 독립적으로 존재하고, 외부와의 상호작용을 통해서만 내부 상태가 변경될 수 있으므로 객체의 안전성과 일관성을 보장할 수 있습니다. 또한, 객체 내부의 데이터와 메서드가 하나의 캡슐에 묶여있기 때문에, 객체의 내부 구현을 변경하더라도 외부에서 영향을 받지 않으므로 유지보수와 확장성 측면에서도 이점을 가지게 됩니다.

따라서, 정보은닉은 객체의 내부 구현을 외부에서 보이지 않게 하는 것에 중점을 두고, 캡슐화는 객체의 내부 데이터와 메서드를 하나로 묶어서 객체라는 하나의 캡슐에 넣는 것에 중점을 둡니다. 두 개념은 객체 지향 프로그래밍에서 객체의 안전성과 일관성을 보장하기 위한 중요한 개념입니다.

Architecture와 Architecture Style의 차이

Architecture는 시스템의 전체적인 설계와 구조를 의미합니다. 시스템의 목적, 기능, 구성 요소, 데이터 구조, 인터페이스, 네트워크 구성 등을 고려하여 설계합니다. 시스템의 구조를 설계함으로써 시스템의 품질과 유지보수성, 확장성 등을 개선할 수 있습니다.

Architecture Style은 특정한 설계 원칙과 패턴을 따라 시스템의 구조를 설계하는 방법을 말합니다. 예를 들어, 클라이언트-서버 아키텍처, RESTful 아키텍처, 마이크로서비스 아키텍처 등이 Architecture Style의 예입니다. Architecture Style은 특정한 목적을 달성하기 위한 구조적인 패턴이며, 특정한 문제를 해결하기 위한 설계 원칙이 담겨 있습니다.

즉, Architecture는 시스템 전체의 구조를 설계하는 데에 대한 개념이고, Architecture Style은 특정한 문제를 해결하기 위한 설계 원칙이 담겨 있는 구조적인 패턴을 의미합니다. Architecture Style은 여러 Architecture 중에서 선택할 수 있으며, 적합한 Architecture Style을 선택하여 시스템의 효율성과 유지보수성을 개선할 수 있습니다.

REST(7가지 제약 조건)

Starting with the Null Style : REST 아키텍처의 기본 원칙은 최소한의 구조를 가진 "null" 시스템으로부터 시작하는 것입니다. 이는 REST 시스템이 간결하고 단순하며 유연하게 구현될 수 있도록 합니다.

Client-Server : 클라이언트와 서버가 독립적으로 진화하며, 서로 간의 의존성을 줄입니다. 이렇게 함으로써 서버와 클라이언트는 각각의 역할에 집중하며 확장성과 이식성을 높일 수 있습니다.

Stateless : 서버는 클라이언트와의 상호작용에서 어떠한 컨텍스트도 저장하지 않습니다. 이렇게 함으로써 서버는 간단하게 구현되며, 서버와 클라이언트 간의 상호작용을 최소화하여 확장성과 가용성을 높일 수 있습니다.

Cache : 클라이언트는 서버의 응답을 캐시하여 이후 요청에 대한 성능을 향상시킬 수 있습니다. 이는 네트워크 지연을 줄이고 대역폭 사용량을 줄일 수 있어, 클라이언트-서버 간의 상호작용을 최적화할 수 있습니다.

Uniform Interface : RESTful 서비스는 Uniform Interface 제약을 따릅니다. 이는 클라이언트와 서버 간의 상호 작용을 단순하게 유지하기 위해 API 인터페이스를 일관성 있게 유지하는 것을 의미합니다. 일관성 있는 인터페이스는 서버 구성 요소, 클라이언트 구성 요소 및 메시지 간 상호 운용성을 개선하며, 확장성을 높이고, 코드의 가독성과 신뢰성을 향상시킵니다.

  • Uniform Interface는 다음과 같은 원칙으로 구성됩니다.

    • Resource Identification in Requests: 각 리소스는 고유한 식별자(URI)를 가지며, 클라이언트는 URI를 통해 리소스를 식별할 수 있습니다.

    • Resource Manipulation through Representations: 클라이언트는 리소스를 조작하기 위해 리소스의 표현(Representation)에만 의존합니다. 서버는 리소스의 표현을 클라이언트에게 제공하며, 클라이언트는 해당 표현을 조작하여 리소스를 조작합니다.

    • Self-descriptive Messages: 메시지는 자체 서술적(self-descriptive)이어야 합니다. 즉, 메시지는 자신이 어떤 형식인지, 어떤 리소스에 대해 어떤 동작을 수행하는지 명확히 전달되어야 합니다.

    • Hypermedia as the Engine of Application State (HATEOAS): RESTful 서비스는 HATEOAS를 지원해야 합니다. 이는 서버가 클라이언트에게 리소스의 상태 전이에 필요한 정보를 포함

Layered System : 클라이언트는 서버와 직접적으로 상호작용하지만, 서버는 다른 서버나 중개자(proxy)와 상호작용할 수 있습니다. 이렇게 함으로써 시스템이 계층화되며, 보안, 로드밸런싱, 공유 캐시 등의 추가 기능을 제공할 수 있습니다. Code-On-Demand : 클라이언트에서 동적으로 기능을 확장하거나, 서버의 부담을 줄이는 등의 기능을 수행할 수 있습니다

PreviousREST APINext2. URI & MIME type

Last updated 1 year ago

📔