Post

SOAP, REST

SOA

Service Oriented Architecture

  • 서비스 지향 Architecture
  • 업무상의 일 🟰 소프트웨어 기능 🟰 서비스
  • 서비스를 네트워크 상에 연동, 시스템 구축

SOAP

Simple Object Access Protocol
exchange structured information over the internet
standard way for applications to communicated each other, regradless of programming language or platform
protocol to exchange XML messages using HTTP, HTTPS, SMTP…

  • 💡 protocol: follow strict standard for communication between client and server
  • 💡 presentaion: all datas are presented in XML
  • 💡 language: WSDL for communication between consumer and provider
  • 💡 saved on UDDI

☑️ WSDL

Web Services Description Language

  • XML based definition language
  • describe web service and their operations, inputs, outputs

  • details of web service
  • help developers understand how to interact with web service
  • where service is provided
  • service message format
  • protocol

☑️ UDDI

Universal Description, Discoverey and Integration

  • registry standard for web services
  • registry for saving, searching web service
  • allow business to publish, discover services over the internet

☑️ ACID

Atomicity, Consistency, Isolation, and Durability

  • SOAP accepts transaction ability

☑️ SOAP message

  • XML format
  • SOAP envelop ➕ SOAP header ➕ SOAP body
  • 👎🏻 complex SOAP message
  • 👎🏻 heavy to be transmitted on HTTP
1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <HelloWorld xmlns="http://example.com/">
      <name>John Doe</name>
    </HelloWorld>
  </soap:Body>
</soap:Envelope>

☑️ SOAP syntax rules

  • SOAP message MUST be encoded using XML
  • SOAP message MUST use SOAP envelope namespace
  • SOAP message MUST NOT contain DTD reference
  • SOAP message MUST NOT contain XML Processing Instructions

👍🏻 Benefits of SOAP

  • 👍🏻 more secure(bank): has SSL and WS security
  • 👍🏻 transaction
  • 👍🏻 ACID
  • 👍🏻 SOA

👎🏻 Disadvantages of SOAP

  • 👎🏻 complex message encoding, decoding
  • 👎🏻 more difficult to develop
  • 👎🏻 more formats to follow than REST
  • 👎🏻 more overhead

ROA

Resource Oriented Architecture

  • 자원 지향 Architecture
  • style of software architecture prioritizing resource
  • 설계 중심: 자원

REST

image

Representational State Transfer
자원의 표현을 가지고 상태를 전달한다.

  • type of architectural structure used to create APIs
  • 웹 서비스 간의 통신을 위한 구조적 졔약 조건

  • 💡 architecture: doesnt follow strict standard like SOAP, but follow six constraints
  • 💡 presentation: HTTP URI
  • 💡 상태: HTTP Status code
  • 💡 전달: HTTP Method

  • REST: present resource in HTTP URI, communicate HTTP Status code with HTTP method
  • RESTful 한 API: API that implements REST architecture style

📌 REST API

Representational State Transfer API

  • HTTP프로토콜로 제공
  • 따라서 핵심 컨텐츠 및 기능을 외부 사이트(핸드폰, 웹, 크롬, 사파리 등)에서 활용할 수 있도록 제공되는 인터페이스
  • REST APIs: used for building web services to communicate over the internet

API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처
웹 상에서 자원을 표현하고 상호작용하는 데 사용되는 인터페이스 설계 원칙
딱 봐도 “아 이런 작업을 하는 API구나!” 알 수 있게 API를 짜야 한다는 의미
REST API는 HTTP 요청을 통해 통신함으로써
리소스 내에서 레코드(CRUD 라고도 함)의 작성, 읽기,업데이트 및 삭제 등의
표준 데이터베이스 기능을 수행

✔️ Resource in Restful API

What is resource in Restful API?

  • Object with data
  • valuable data unit in network

👍🏻 Benefits of Rest API

  • 👍🏻 Simple, easier to implement
  • 👍🏻 Flexible to communicate with different platforms and languages

📌 Rest Architecture 6 conditions

  • client-server
  • stateless
  • cache
  • layered system 계층화
  • uniform interface 인터페이스 일관성
  • code-on-demand(optinal)

✔️ client-server decoupling

  • 클라이언트와 서버 분리 따라서 각각의 역할 명확
  • 👍🏻 각각 독립, 서로 의존성 ⬇️
  • 👍🏻 유연한 시스템 구축
  • 👍🏻 각 필드에서 개발해야 할 점 명확

    • 클라이언트:
    • request
    • manage resource context(state, session, login information)
    • 요청된 리소스의 URI

    • 서버:
    • respond
    • provide API
    • HTTP를 통해 요청된 데이터를 클라이언트에게 전달

✔️ stateless

  • each request is independent

  • HTTP is stateless, thus REST is also stateless
  • server does not rememeber resource context(state) of previous resource
  • server processes all requests individually
  • 👍🏻 server does not have to pay attention to resourse context(session management)

✔️ cacheable(캐시 가능)

  • REST uses HTTP, can use HTTP cache
  • 캐시 기능을 이용하여 응답 결과를 저장해두고 재사용
  • temporarily store data from server, respond to repeated requests for same data
  • 👍🏻 서버 부하 ⬇️
  • 👍🏻 응답 속도 ⬆️ 성능 향상

✔️ layered System(게층화 구조)

Screenshot 2024-08-28 at 17 09 24

  • 여러 계층으로 구성 가능
  • each layer carries specific responsibility, functionality
  • 👍🏻 flexibility such as security, load balancing, encryption
  • 👍🏻 intermediary such as gateway, proxy

✔️ Uniform Interface

  • REST has certain standard, restrictions when communicating

    1. URI: Each resource should be identified with URI(Uniform Resource Identifier)
    1. Representation: Clients must have specific format to represent information recieved (JSON, XML)
    1. self-descriptive message: message should be able to explain itself
    1. HATEOAS: Hypertet As The Engine Of Application State
      • use links to direct the state of represented resources
      • application status should be transmitted through Hyperlink
      • can use service without relying extensively on external documentation

✔️ method(표준화된 메소드)
일반적으로 HTTP 메소드를 이용해 자원에 대한 조작을 수행
사용되는 메소드로는 GET, POST, PUT, DELETE 등

✔️ code-on-demand(optinal)

  • code server sends a code to client
  • client recieves code and runs
  • 👍🏻 allow client to start with lighter application and if needed, expand capabilities
  • 👎🏻 reduces visibility

☑️ 지키기 어려운 uniform interface

  • 리소스가 URI로 식별되어야 한다.
  • 리소스를 생성, 수정, 추가하고자 할 때 HTTP에 표현을 해서 전송해야 한다.
  • 이 두가지가 적용이 어려움
    • 메세지는 스스로를 설명할 수 있어야 한다. self-descriptive message
    • 애플리케이션의 상태는 hyperlink를 통해 전송되어야 한다. HATEOAS

여기서 self-descriptive message 부분과 HATEOAS는 API로 구현하기가 쉽지 않다.
그래서 WEB API 또는 HTTP API를 사용하기도 한다.
💡 그래서 Rest라고 하면서 Rest의 모든 것을 지키지 않거나,
WEB API 또는 HTTP API를 Rest라고 부르기도 한다.

Screenshot 2024-08-03 at 10 40 49

📌 WEB API

  • REST의 정확한 정의대로 API를 만드는 것은 쉽지 않기에 WEB API를 사용하기도 한다.

  • URI는 정보의 자원을 표현해야 한다.
  • 자원에 대한 행위는 HTTP Method로 표현한다.

☑️ ⭕️❌ 문제

HTTP Method⭕️❌
GET /members/1⭕️
GET /members/get/1❌ 동사로 표현하면 안된다.
GET /members/add
POST /members⭕️
GET /members/update/1
PUT /members/1⭕️
GET /members/del/1
DELETE /members/1⭕️

☑️ 그 외 규칙

  • 슬래시 /는 계층을 나타낼 때 사용
  • URI는 마지막 문자로 /를 포함하지 않는다.
  • 하이픈-은 가독성을 높일 때 사용한다.
  • 언더바_는 사용하지 않는다.
  • URI 경로로는 소문자만 사용한다.

📌 Richardson Maturity Model

framework to evaluate maturity of web server adherence to RESTful principles
how much the web service is REST compliant

☑️ Three main factors to decide maturity

  • URI
  • HTTP Methods
  • HATEOAS

  • more factors ⬆️ higher maturity level ⬆️

☑️ Maturity Level

Screenshot 2024-08-28 at 17 20 21

✔️ Level 0: single URI and single Verb

  • the swamp of POX
  • does not make use any URI, HTTP Methods, HATEOAS
  • use single HTTP verb POST
  • only one endpoint
  • use HTTP as tunneling mechanism
  • use POX(Plain Old XML) to request, response
  • RPC(Remote Procedure Call) style

✔️ Level 1: multiple URIs and single Verb

  • make use of URIs, but does not use HTTP Mehods, neither HATEOAS
  • multiple URIs to represent resrouce
  • use single HTTP verb POST
  • use HTTP as tunneling mechanism

  • 👍🏻 use divide and conquer and deal with complexity

✔️ Level 2: multiple URIs and multiple Verbs

  • use multiple HTTP verbs(CRUD)
  • use HTTP status code
  • use HTTP as tunneling mechanism

  • 👍🏻 메소드의 표준 집합 도입

✔️ Level 3: HATEOAS

  • fully use URIs, HTTP Methods, HATEOAS
  • HATEOAS: server can change URI scheme, irrelevant to client

  • 👍🏻 프로토콜이 스스로 문서화할 수 있는 방법 제공
  • 👍🏻 발견가능성 discoverability

SOAP 🆚 REST

Screenshot 2024-08-28 at 13 39 50

  • 공통점: two different ways to connect applications with server-side data

  • REST can use SOAP, whereas SOAP cannot use REST

✅ MashUp

서비스 업체들이 다양한 RestAPI를 제공함으로써, 이러한 RestAPI를 조합해 만든 어플리케이션

This post is licensed under CC BY 4.0 by the author.