API란 ?

API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.
주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.
인터페이스(interface)는 컴퓨터 시스템끼리 정보를 교환하는 공유 경계를 의미한다.
따라서 api는 어떠한 응용프로그램에서 데이터를 주고 받기 위한 방법을 의미한다.

수집하고 있는 정보를 사용자에게 쉽게 제공하기 위한 목적으로 만들어진다.

REST ?

Representational State Transfer (표현 상태 전이, REST)
HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식
HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
REST API는 리소스를 나타낼 때 URI(Uniform Resource Identifier)를 사용한다.

REST 구성

  • 자원 (Resouce) - URI
  • 행위 (Verb) - HTTP Method
  • 표현 (Representations)
예) /users GET
      /users/{id} GET
      /users PUT

REST의 장단점

  • REST의 장점 1) 사용이 쉽다
  • REST API는 사용이 쉽다. REST API 메시지 자체를 그냥 읽기만 하는 것으로도 메시지의 본래 의도를 파악할 수 있을 정도로 쉽게 이해가 된다. 또 한 기존 HTTP 인프라를 그대로 이용하기 때문에 REST를 사용하기 위해 별도의 인프라를 요구할 필요가 없다. 또 한 Stateless이기 때문에 세션과 요청 내용이 연관되지 않기 때문에 요청이 수행 컨텍스트(Context)에 독립적이다. 따라서 이해하기 쉽고, 사용하기 쉽다.

2) Client-Server가 명확히 분리된다.

  • 클라이언트는 REST API를 통해 서버와 정보를 주고 받는다. 서버 입장에서는 클라이언트의 수행 컨텍스트를 유지할 필요가 없다. 즉, 별도의 세션 정보를 유지할 필요가 없고, 단지 클라이언트에서 요청한 내용만 처리해서 응답하면 된다. 이는 클라이언트와 서버의 역할을 명확하게 분리해서 REST API의 제공과 사용으로 분리하여 개발할 수 있다. 심지어 HTTP 프로토콜만 서비스하면 되기 때문에 플랫폼과도 독립적이어서 멀티 플랫폼 상황에서 서비스를 쉽게 개발할 수 있게 해준다. (리눅스 서버에 떠 있는 웹 서버에 윈도우에서 동작하는 웹 브라우자가 붙어서 동작할 수 있다.)

3) 원하는 데이터 표현을 사용할 수 있다.

  • REST API는 헤더부분에 URI에 대한 처리 메소드를 명시하고, 필요한 실제 데이터는 body부분에 표현하도록 분리시켰다. 페이로드부분을 JSON, XML, YAML 등 원하는 표현 언어로 사용할 수 있다는 장점이 있다.

  • REST의 단점 1) HTTP 메소드의 한계에 묶인다.
  • REST API는 HTTP 메소드를 이용하여 URI에 대한 행위를 정의한다. 따라서 간단한 수준의 메소드만 지원할 수 있다. 예를 들어 ‘메일을 보낸다.’라는 행위는 단일 메소드로 구현하기 쉽지 않은 일이다. 2) 표준이 없어서 관리하기 어렵다
  • REST API는 API 설계 가이드일 뿐이지 명시적인 표준이 아니다. 따라서 관리가 어렵고, 좋은 API 디자인에 대한 가이드가 쉽지 않다. 어떤 가이드는 특정한 REST API에는 맞지만 또 다른 곳에는 맞지 않을 수 있다. 3) RDBMS와 어색한 관계
  • REST API를 RDBMS에 적극적으로 사용하기 위해서는 RESTful 한 테이블 구조가 필요하게 되는데, 이것보다는 NoSQL쪽이 더 잘 맞는 추세다.
[참고] REST API란 무엇인가, RESTful한 서비스 아키텍처 작성자 이즈군

REST Architecture 6가지 원칙 (RESTful)

  • 균일한 인터페이스 Uniform interface
    • HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용이 가능하며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다. HTTP를 사용하는 모든 플랫폼에서 요청가능하며, Loosely Coupling(느슨한 결함) 형태를 갖는다.
  • 상태없음 Stateless
    • HTTP는 Stateless Protocol 이므로, REST 역시 무상태성을 갖는다. 즉, HttpSession과 같은 컨텍스트 저장소에 상태정보를 따로 저장하고 관리하지 않고, API 서버는 들어오는 요청만을 단순 처리하면 된다. 세션과 같은 컨텍스트 정보를 신경쓸 필요가 없어 구현이 단순해진다. 이러한 무상태성때문에 Rest API는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순합니다. 이러한 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함이다.
  • 캐시 Cacheable
    • HTTP 기존의 웹 표준을 그대로 사용하므로, 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다. HTTP 프로토콜 기반의 로드밸런서(mod_proxy)나, SSL은 물론이고 HTTP가 가진 가장 강력한 특징 중의 하나인 캐싱 기능을 적용할 수 있다.
      HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있고, 이것은 대량의 요청을 효울척으로 처리할 수 있게 도와줍니다.
  • 클라이언트/서버 Client/Server
    • REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보 등)을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다. 서로 독립적
  • 계층 시스템 Layered system
    • API 서버는 순수 비지니스 로직을 수행하고, 그 앞단에 사용자 인증, 암호화(ssl), 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연성을 둘 수 있다. 이는 간단하게는 HA Proxy나 Apache의 Reverse Proxy를 통해, 더 나아가서는 API gateway 등을 활용하여 Micro Service Architecture로도 구현이 가능하게 한다. 하지만 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없습니다.
  • 자체 표현 Self-descriptiveness
    • 동사(Method) + 명사(URI) 로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 알 수 있으며, 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조로, REST API 메시지만 보고도 이를 쉽게 이해할 수 있다.
  • Code on demand(조건부)
    • 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.

REST API

REST 기반으로 서비스 API를 구현한 것
사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.

  • RESTful : REST API의 설계 의도를 정확하게 지켜주는 API

  • RESTful API 설계
    1. URI는 정보의 자원을 표현해야 한다.(리소스명은 동사보다는 명사를 사용)
    2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현
  • URI 설계시 주의할 점
    1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
    2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
    3. 하이픈(-)은 URI 가독성을 높이는데 사용
    4. 밑줄(_)은 URI에 사용하지 않는다.
    5. URI 경로에는 소문자가 적합하다.
    6. 파일확장자는 URI에 포함하지 않는다.
    • 정리
      • rest란 웹을 효율적으로 사용하기위한 아키텍처인데, 웹 기존의 http를 기반으로 인프라를 사용하기에 캐싱 사용가능하고 모든 플랫폼,언어에 사용가능하고 rest api메세지만 보고도 구분하기 편해서 사용하기에 쉽다. 하지만 간단한 수준의 메소드만 가능하고 표준이 없어 관리하기가 어렵다. rest설계의도를 정확하게 지킨 api를 restful api라고 한다.