RESTful API

EJ·2021년 1월 13일

기술 공부

목록 보기

9/18

API

Application Programming Interface

API는 애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트다.

API를 사용하면 구현 방식을 알지 못해도 제품 또는 서비스가 서로 커뮤니케이션 할 수 있으며, 애플리케이션 개발을 간소화해 시간과 비용의 절약이 가능하다. 즉, 프로그램들이 서로 상효작용하는 것을 도와주는 매개체라고 볼 수 있다.

API의 역할

서버와 데이터베이스에 대한 출입구 역할을 한다.
: 데이터베이스에는 여러 정보들이 저장된다. API는 이 정보들에 대해 허용된 사람들만 접근할 수 있도록 접근성을 부여해준다.
애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
: 애플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 한다.
모든 접속을 표준화한다.
: 모든 접속을 표준화하기 때문에 기계/운영체제 등과 상관없이 누구나 동일한 액세스를 얻을 수 있다. 범용 플러그처럼 작동하는 것이다.

API 유형

private API
: 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발생하는 API이다. 제3자에게 노출되지 않는다.
public API
: 개방형 API로 모두에게 제공된다. 누구나 제한 없이 사용 가능하다.
partner API
: 기업이 데이터 공유에 동의하는 특정인만 사용 가능하다. 비즈니스 관계에서 사용되며, 파트너 회사 간 소프트웨어 통합을 위해 사용된다.

API 사용시 이점

private API를 이용할 경우, 개발자들이 애플리케이션 코드를 작성하는 방법을 표준화함으로써 간소화되고 빠른 프로세스 처리가 가능해진다. 또한, 소프트웨어를 통합하고자 할 때 개발자 간의 협업이 용이해진다.

public API와 partner API를 사용할 경우, 기업은 타사 데이터를 활용해 브랜드 인지도를 높일 수 있으며 고객 데이터 베이스를 확장해 전환율까지 높일 수 있다.

RESTful API

REST

REpresentational State Transfer

REST란 어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 요청을 보내는 것이다.

Get, Post 등의 방식을 사용해 요청을 보낸다.

REST의 특징

1. Uniform Interface(일관된 인터페이스)

Resource(URI)에 대한 요청을 통일되고 한정적으로 수행하는 스타일을 의미한다.
요청을 하는 클라이언트가 플랫폼(Android, Ios, Jsp...)에 무관하며 특정 언어나 기술에 종속 받지 않는 것이다.

이러한 특징 덕분에 Rest API는 HTTP를 사용하는 모든 플랫폼에서 요청이 가능하며, 느슨한 결함(Loosely Coupling) 형태를 가지게 된다.

2. Stateless(무상태성)

서버는 각각의 요청을 별개의 것으로 인식하고 처리해야 하며, 이전 요청이 다음 요청에 연관되어서는 안된다. 따라서 Rest API는 세션 정보나 쿠키 정보를 활용함으로써 작업을 위한 상태 정보를 저장/관리하지 않는다.

이러한 무상태성 덕분에 Rest API는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다.
(서버의 처리 방식에 일관성을 부여하고, 서버의 부담을 줄여준다.)

3. Cacheable(캐시 가능)

Rest API는 HTTP라는 기존의 웹표준을 그대로 사용하기 때문에, 웹의 기존 인프라를 그대로 사용할 수 있다. 따라서 캐싱 기능을 적용할 수 있다.

캐싱을 구현함으로써 대량의 요청을 효율적으로 처리할 수 있게 도와준다.

4. Client-Server Architecture(서버-클라이언트 구조)

Rest API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며, 클라이언트는 사용자 인증, Context(세션, 로그인정보) 등을 직접 관리하는 등의 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다.

5. Self-Descriptiveness(자체 표현)

Rest API는 요청 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

예를 들어, 아래와 같은 JSON 형태의 Rest 메세지는 http://localhost:8080/insertBoardInfo로 게시글의 제목, 내용을 전달하고 있음을 쉽게 이해할 수 있다.

HTTP POST , http://localhost:8080/insertBoardInfo
{
  "boardVO":
    "title":"제목",
    "content":"내용"
  }
}

6. Layered System(계층 구조)

Rest API의 서버는 다중 계층으로 구성될 수 있으며, 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가해 구조를 변경할 수 있다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간 매체를 사용할 수 있게 해준다. 하지만 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없다.

RESTful API

REST 기반의 API를 웹으로 구현한 것이 RESTful API이다.

RESTful API의 구성요소

Resource

서버는 유니크한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보낸다. 이러한 Resource는 ✔️URI에 해당한다.

Method

서버에 요청을 보내기 위한 방식이다. GET, POST, DELETE가 있으며, 처리를 위한 연산에 맞는 Method를 사용해 서버에 요청을 보내야 한다.

Representation of Resource

클라이언트와 서버가 데이터를 주고받는 형태로 json, xml, rss 등이 있다. 최근에는 key, value를 활용하는 json을 주로 사용한다.

✔️ URI과 URL
URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미한다.

URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URL을 포함하게 된다. 그러므로 URI가 보다 포괄적인 범위라고 할 수 있다.

REST API 설계 규칙

1. URI는 정보의 자원을 표현해야 한다.

Resource는 동사보다는 명사, 대문자보다는 소문자를 사용한다.
Resource의 스토어 이름으로는 복수 명사를 사용해야 한다.

2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.

HTTP Method나 동사표현이 URI에 들어가면 안된다.
:id와 같이 변하는 값은 하나의 특정 Resource를 나타내는 교유값이어야 한다.
흔히 하는 실수는 URI에 자원에 대한 행위를 넣는 것이다.
```
// 잘못된 사례

GET /chatrooms/get/:id
POST /chatrooms/create
GET /chatrooms/delete/:id
POST /chatrooms/update/:id
```
위 잘못된 사례는 아래와 같이 고칠 수 있다.
```
// 올바른 사례

GET /chatrooms/:id
POST /chatrooms
DELETE /chatrooms/:id
PUT /chatrooms/:id
```

3. HTTP Method

주로 쓰는 Method

GET : 요청받은 URI의 정보를 검색해 응답한다. (조회)
POST : 요청된 자원을 생성한다.
PUT : 요청된 자원을 수정(update)한다. 자원 전체를 갱신한다.
PATCH : PUT과 유사하게 요청된 자원을 수정하지만, 해당 자원의 일부만 교체한다.
DELETE : 요청된 자원을 삭제할 것을 요청한다.(안전성 문제로 대부분의 서버에서 비활성)

나머지 Method

HEAD : GET과 유사하지만 응답에 BODY가 없고 응답코드와 HEAD만 응답한다.(웹서버 정보확인, 헬스체크, 버전확인, 최종수정일자확인 등의 용도로 사용)
OPTION : 웹서버에서 지원되는 메소드의 종류를 확인할 경우 사용한다.
TRACE : 리퀘스트 라인과 헤더를 그대로 클라이언트에 반송(리퀘스트 치환상태를 조사할 때 사용)
CONNECT : 암호화된 메세지를 프록시로 전송

4. 설계 예시

CRUD	HTTP	URI
전체 리소스 조회	GET	/resources
특정 리소스 조회	GET	/resources/:id
리소스 생성	POST	/resources
리소스 전체 수정	PUT	/resources/:id
리소스 일부 수정	PATCH	/resources/:id
특정 리소스 삭제	DELETE	/resources/:id

HTTP Method

POST와 PUT의 차이

POST는 insert, PUT는 update의 개념으로 생각하면 쉽다. POST는 멱등하지 않지만 PUT는 멱등하다.

예를 들어, POST의 경우 클라이언트가 리소스의 위치를 지정하지 않는 경우 사용된다. 아래처럼 같은 요청이 여러 번 수행될 경우 매번 새로운 dog(dogs/3, dogs/4)가 생성되게 된다.

POST /dogs HTTP/1.1
{ "name": "blue", "age": 5 }
HTTP/1.1 201 Created

PUT의 경우 클라이언트가 명확하게 리소스의 위치를 지정한다. 따라서 여러 번 요청이 수행되어도 리소스의 위치가 지정되어있기 때문에 새로운 자원이 생성되지 않는다. 아래 예시를 보면 동일한 리소스(dogs/3)을 수정하게 된다.

PUT /dogs/3 HTTP/1.1
{ "name": "blue", "age": 5 }

PUT과 PATCH의 차이

PUT은 해당 자원의 전체를 교체하지만, PATCH는 일부만 변경한다. PUT은 멱등하지만, PATCH는 멱등하지 않다.

PUT은 전체 자원을 업데이트하기 때문에 동일 자원에 대해 동일하게 PUT을 처리할 경우 멱등하게 처리된다.
반면, PATCH로 처리되는 경우 자원의 일부만 변경되기 때문에 멱등성을 보장할 수 없게 된다.

💡 요약
API는 애플리케이션을 구축하고 통합하기 위한 프로토콜로, 프로그램들이 서로 상호작용하는 것을 도와주는 매개체라고 볼 수 있다.

API에는 private API, public API 등이 있다. 또, REST 기반의 API를 웹으로 구현한 RESTful API도 있다.

REST란 웹 상에 존재하는 모든 자원에 URI(resource)을 부여해서 접근하는 방식이다. 이러한 REST를 기반으로 구현되는 RESTful API는 자원에 대한 작업을 HTTP Method를 통해 표현하게 된다.

HTTP Method에는 GET, POST, PUT, PATCH, DELETE 등이 있다.

GET은 요청받은 정보를 검색해 응답하고, POST는 요청한 자원을 생성한다. PUT과 PATCH는 요청된 자원을 수정하며, DELETE는 요청된 자원을 삭제할 것을 요청한다.

주니어 프론트엔드 개발자 👼🏻

이전 포스트

브라우저 저장소 - LocalStorage, SessionStorage, Cookie

다음 포스트

RESTful API

기술 공부

API

API의 역할

API 유형

API 사용시 이점

RESTful API

REST

REST의 특징

1. Uniform Interface(일관된 인터페이스)

2. Stateless(무상태성)

3. Cacheable(캐시 가능)

4. Client-Server Architecture(서버-클라이언트 구조)

5. Self-Descriptiveness(자체 표현)

6. Layered System(계층 구조)

RESTful API

RESTful API의 구성요소

Resource

Method

Representation of Resource

REST API 설계 규칙

1. URI는 정보의 자원을 표현해야 한다.

2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.

3. HTTP Method

4. 설계 예시

HTTP Method

POST와 PUT의 차이

PUT과 PATCH의 차이

브라우저 저장소 - LocalStorage, SessionStorage, Cookie

JavaScript는 어떤 언어인가 + Web Worker

0개의 댓글