swift

API 파헤치기[1] (API, REST, parameter)

햄지이 2022. 6. 15. 21:10

API란?

application Programmimg interface 의 약자이다.

서로 다른 하드웨어에 코드작성을 일일히 하는 업무를 줄이기 위해서 함수 하나를 만들어 각각의 하드웨어에 쓸수있게 하기위해서 개발되었다

API는 프로그램과 또 다른 프로그램을 연결해주는 일종의 매개체 역활을 한다.

- 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하고 서로 정보를 교환가능 하도록 하는 것

- 응용 프로그램(애플리케이션)에서 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

 

네트워크 통신의 종류

앱과 서버 간 네트워크 통신이 이루어지는 방식은 크게 두 가지로 구분해 볼 수 있습니다.

하나, TCP/UDP를 사용하는 소켓 방식의 연결성 통신

또 다른 하나는 HTTP, HTTPS, SMTP 등의 프로토콜을 이용한 비연결성 통신입니다.

 

1-0 소켓방식의 연결 지향 통신

소켓을 이용한 네트워크 통신 방식은 보통 "저수준"통신을 통하여 구현됩니다.

전구가 결합하는 소켓의 개념을 따온 소켓 방식의 연결은 일단 앱과 서버가 연결되면 한쪽에서 명시적으로 끊을때까지

지속해서 연결을 유지하는 방식입니다.

 

1-1  비연결 지향 통신

TCP/UDP를 이용하는 소켓방식과 달리, HTTP등의 프로토콜을 사용하여 메시지를 주고 받는 방식입니다.

비연결성 프로토콜은 요청이 들어오면 이에 맞는 응답을 보낸 후 바로 연결을 종료합니다.

다시 요청을 하기 위해서는 새롭게 연결을 맺어야 한다, 비연결 방식이라 하여 아예 연결을 하지 않는다는 뜻은 아니다,

단지 연결을 유지하지 않는 것일 뿐입니다.

 

SOAP방식

SOAP은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등의 프로토콜을 통해 양쪽에서 XML 형태의 메시지를 주고받도록 구현된 프로토콜이다.

 

RESTful방식

RESTful의 근간이 되는 REST는 월드 와이드 웹과 같은 분산 하이퍼 미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식

REST란 웹 형식을 빌어 데이터를 전송하되, SOAP나 쿠키 등 별도의 전송 프로토콜 없이 전송하기 위해 만들어진 간단한 형식의 인터페이스이다.!

 

RESTful 시스템은 네트워크 서버를 통해서뿐만 아니라 일반 웹 서버를 통해서도 약간의 설정만으로 쉽고 간단하게 구현할 수 있다는 장점이 있어 널리 확산되고 있습니다.(현시점에서 보편적으로 가장많이 쓴다고합니다.)

 

XML방식

XML 방식이란 요청에 대한 응답 데이터를 XML 포맷으로 제공하는 것을 말합니다.

SOAP 방식의 요청이나 RESTful API 모두 XML 방식으로 만들어진 결과를 제공 할 수 있습니다.

 

XML은 W3C에서 특수 목적의 마크업 언어를 만드는데에 권장하는 다목적 마크업 언어이다.

XML은 일반적으로 태그라고 불리는 마크업과 내용으로 구성된다.

태그는 '<'로 시작하여'>'로 끝나는 구조를 가진다.

시작태그<element>

끝태그</elemet>

빈요소태그<elemet/>

시작과 끝이 짝을 이룬다,  하위 계층을 이루는 태그 쌍이 포함될 수도 있다, 이렇게 데이터의 계층 구조가 만들어집니다.

 

오른쪽 사진과 같이 XML 형식의 마크업으로 전달된 데이터는 그대로 사용할 수 있는 것이 아니라 데이터를 형식에 맞게 분석하는 과정이 필요하다. 이 과정을 파싱(Parsin)이라 하고, 파싱을 처리하는 모듈을 파서(Parser)라고 합니다.

 

 

 

 

 

REST API란?

REST기반의 서비스 API를 구현한 것을 의미한다.

REST API 에서 REST는 Representational State Transfer 의 약자로 소프트웨어 프로그램 아키텍처의 한 형식 입니다.

즉, 자원을 이름 (자원의 표현) 으로 구분하여 해당 자원의 상태 (정보)를 주고 받는 모든 것을 의미한다.

월드 와이드 웹 (WWW) 과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

 

REST의 구체적인 개념

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

즉, REST는 자원 기반의 구조 (ROA: Resource Oriented Architecture) 설계의 중심에 Resoure가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.

웹의 모든 자원에 고유한 ID인 HTTP URI 를 부여한다.

 

 

 

우리는 왜 RESTful APIs를 만드는 것일까?

RESTful APIs 개발하는 가장 큰 이유는 Client Side를 정형화된 플랫폼이 아닌 모바일, PC, 어플리케이션 등 플랫폼에 제약을 두지 않는 것을 목표로 했기 때문 입니다.

즉, 2010년 이전만 해도 Server Side에서 데이터를 전달해주는 Client 프로그램의 대상은 PC 브라우저로 그 대상이 명확 했다. 그렇다 보니 그냥 JSP ASP PHP 등을 잉요한 웹페이지를 구성하고 작업을 진행하면 됐다.

하지만 스마트 기기들이 등장하면서 TV, 스마트 폰, 테블릿 등 Client 프로그램이 다양화 되고 그에 맞춰 Server를 일일이 만다는 것이 꽤 비효율적인 일이 되어 버렸다.

이런 과정에서 개발자들은 Client Side를 전혀 고려하지 않고 메시지 기반, XML, JSON과 같은 Client에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향하게 되면서 Server와 Client의 역할을 분리하게 되었다.

 

REST의 구성  (참조자료)

자원(Resource) - URL

행위(Verb) - Http Method

표현(Representations)

 

1.자원 (Resource) URL

-모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.

자원을 구별하는 ID는 /orders/order_id/1 와 같은 HTTP URI 이다.

2. 행위 (Verb) - Http Method

HTTP 프로토콜의 Method를 사용한다.

HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

3. 표현 (Representaion of Resource)

Client가 자원의 상태 (정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답 (Representation)을 보낸다

REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.

현재는 JSON으로 주고 받는 것이 대부분이다.

 

RESTful API에서 HTTP 메소드의 종류

GET - 특정 리소스의 대표적인 정보를 요청할때

POST - ID 없이 리소스를 생성하거나 수정할때

PUT - ID 기반으로 리소스를 생성하거나 수정할때

DELETE - 리소스를 삭제할때

HEAD - GET 방식이 요청이지만 내용 없이 메타 정보만 요청할때

OPTUINS - 특정 URL에 대한 보조 메소드 역활

 

RESTful API와 HTTP 전송방식

일반적으로 서버에 요청하는 정보의 타입은 쓰기, 읽기, 수정, 삭제의 네 가지로 구분됩니다.

이 네 가지 합하여 CRUD라고 부르는데, 각각 쓰기(Create), 읽기(Read), 수정(Update), 삭제(Delete) 의 첫 글자를 딴 것입니다.

 

REST 의 특징

a. 클라이언트 / 서버 구조

-클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역활이 확실하게 구분되고 일괄적인 인터페이스로 분리되어 작동할 수 있게 한다

 

b. 무상태성 (Stateless)

-REST는 HTTP의 특성을 이용하기 떄문에 무상태성을 갖는다.

 

c. 캐시 처리 가능 (Cacheable)

-HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.

 

d. 자체 표현 구조 (Self - descriptiveness)

-JSON을 이용한 메시지 포멧을 이용하여 직관적으로 이해할 수 있고 REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.

 

e. 계층화 (Layered System)

-클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다

 

f. 유니폼 인터페이스 (Uniform)

-Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다

 

 

RESTful 이란

-HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.

-'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다.

-RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.

 

 

RESTful API 개발 원칙

1. 자원을 식별할 수 있어야한다.

URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.

Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.

 

2.행위는 명시적이어야 한다.

REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.

다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.

 

3.자기 서술적이어야 한다.

데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.

즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다

 

4.HATEOS(Hypermedia as the Engine of Application State)

클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.

REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.

이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.

클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.

 

REST의 단점들

  1. REST는 point-to-point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 연결을 맺고 상호작용해야하는 어플리케이션의 개발에는 적당하지 않다.
  2. REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 보안과 통신규약 정책 같은 것은 전혀다루지 않는다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
  3. HTTP에 상당히 의존적이다. REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만 자연스러운 개발이 힘들다. 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 상황이기에 큰 단점이 아니게 되었다.
  4. CRUD 4가지 메소드만 제공한다. 대부분의 일들을 처리할 수 있지만, 4가지 메소드 만으로 처리하기엔 모호한 표현이 있다.

 

{

Query parameter

query string 파라미터: 쿼리문 내의 파라미터. 엔드포인트가 끝난 뒤 물음표 뒤에 온다.

엔드포인트에서 물음표(?) 뒤에 등장하는 query 파라미터는 다음과 같은 형식을 지닌다.

/surfreport?days=3&units=metric&time=1400

가끔 path 파라미터와 query 파라미터 중 무엇을 사용할지 고민하곤 하는데, REST API의 모범을 준수하자면 path 파라미터는 특정 리소스를 정의할 필요가 있을 때, query 파라미터는 정렬 혹은 필터링이 필요할 때 사용한다.

 

body parameter

- request body 파라미터: 리퀘스트 바디에 포함된 파라미터. 보통 JSON 형식으로 제출된다.

보통 POST 리퀘스트에서는 JSON 오브젝트를 리퀘스트 바디 안에 넣어 보낸다.

이것이 바로 request body 파라미터이며 주로 JSON으로 되어 있다.

{

"days": 2,

"units": "imperial",

"time": 1433524597

}