API

• API는 Application Programming Interface로 응용 프로그램에서 사용할 수 있도록 OS나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스이다.

  ex) 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스

  

  • API는 인터페이스이므로 실제 어떻게 동작하는지 API 사용자(개발자)가 구현하지 않고, API 제공자가 구현한다. 개발자는 API에서 제공하는 기능을 사용할 뿐이다.
    • API 제공자) 다양한 API 제공자가 있으며 REST API, GrahpQL 쿼리에 대한 응답을 제공하는 Server 등이 있다.

• 왜 API를 사용하는가?

  API를 사용하면 특정 소프트웨어의 구현 방식을 몰라도 프로그램들이 서로 상호작용 할 수 있어 개발을 편리하게 할 수 있도록 해준다.
  

• API 접근 방식

  아키텍처와 사용 범위에 따라 분류한다.

  • Private API : 기업, 연구 단체 등에서 애플리케이션과 시스템의 통합을 위해 사용하는 것으로 단체 내부에서만 사용할 수 있다.
  • Partner API : 특정 비즈니스 파트너와 공유하여 수익 창출을 목표로 사용한다.
  • Public API : 모든 사람들에게 API를 제공하는 것으로, 개인이 API와 상호작용 하는 프로그램을 무료로 개발할 수 있다.

• API 장점

  • 개발 및 관리의 효율성 : 실제 서비스가 어떻게 구현되는지 몰라도 서비스를 사용할 수 있기 때문에 개발 시간이 줄고, 비용을 줄일 수 있다. 또한 API 문서만 보면 쉽게 이해할 수 있기 때문에 협업에 용이하고 유지보수가 수월하다.
  • 유연성, 확장성 용이 : 사용자의 환경에 맞춰 정보를 전달 받을 수 있으며 직접 액세스 하지 않아도 콘텐츠가 자동으로 생성, 업로드 되기 때문에 확장이 용이하다. 예를 들어, 새롭게 추가할 기능 중 하나가 지도인 경우 직접 지도를 개발하지 않고 구글이나 네이버에서 제공하는 지도를 사용하면 된다.

• API 동작원리

  • 사용자로부터 Request를 받아 결과값을 Parsing한다.
  • 요청 방법으로 REST, SOAP, XML-RPC 등의 형식이 있으며 REST 방식으로 API 가장 많이 제공한다.

• 오픈 API

  • 누구나 쓸 수 있도록 공개된 API로 공공데이터포털(www.data.go.kr)를 통해 국가 기관이 보유한 데이터를 API 형태로 받을 수 있으며 카카오, 네이버, 구글 등 민간기업에서 제공하는 자사의 다양한 기능들(지도, 검색, 로그인 기능 등)을 자유롭게 사용할 수 있다.

REST API를 알기 전 REST란 무엇인가?

• REST(Representational State Transfer)
  • 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미
  • HTTP URI를 통해 자원을 명시 - HTTP Method를 통해 자원에 대한 CRUD 적용
  • REST 구성요소
    • 자원(Resource) : URI
    • 행위(Verb) : Method (각 메소드는 CURD에 매핑) (GET- read 조회, POST- create 생성, PUT- update/replace 바꾸기(자원의 전체를 수정), PATCH- update/modify 업데이트(자원의 일부를 수정) , DELETE- delete 삭제)
      
    • 표현(Representations) : 행위의 내용(JSON, XML 등의 형태로 표현)
  • Rest 특징
    • 서버-클라이언트 구조 서버와 클라이언트 구조가 분명하기 때문에 서로의 의존성이 줄어든다. (서버- API 제공/ 클라이언트 - 사용자 인증, 세션, 로그인 관리)
      
    • Stateless(무상태) 작업에 대한 상태 정보(세션, 쿠키)를 따로 저장, 관리하지 않는다. 따라서 API 서버는 단 순히 요청만을 처리하면 되기 때문에 서비스의 자유도가 높아진다.
      
    • Uniform Interface(인터페이스 일관성) URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
      
    • Cacheable(캐시 가능) HTTP라는 기존 웹 표준을 그대로 사용하기에 http가 가진 캐싱 기능을 적용할 수 있다. (* 캐싱 : 서버에서 데이터를 가져오는 것이 아닌 이전에 본인 디스크나 메모리에 저장해뒀다가 데이터를 읽어오는 것으로 빠른 속도로 데이터를 가져올 수 있다.)
      
    • Self-descriptiveness(자체 표현 구조) REST API 메시지만 보고 쉽게 이해 할 수 있는 자체 표현 구조이다.
      
    • 계층형 구조 REST 서버는 다중 계층으로 구성 가능하여 구조상의 유연성을 둘 수 있다.
      

- Rest API

• REST 원칙을 기반으로 서비스 API를 구현한 것
• 요청 자체로 Represnet 표현하자의 의미로 클라이언트와 서버가 고유한 URL을 통해 요청과 응답을 주고 받을 때, URL만 보고 어떤 내용의 요청인지 추론할 수 있다.
• 중요- 정보의 자원은 URI로 표현하고 , 자원에 대한 행위는 HTTP Method로 표현
• REST API의 설계 규칙을 올바르게 지킨 시스템을 ‘RESTful하다’라고 말한다.
• URI 설계 시 주의할 점
  • 슬래시 구분자(/)는 계층 관계를 나타내는데 사용, 마지막에 (/)을 포함하지 않는다.
  • 언더바(_) 대신 하이픈(-)을 사용한다.
  • CURD 행위는 포함하지 않는다.
  • 동사보다는 명사를 대문자보다는 소문자를 사용한다. Bad ex) http://kjy127.com/testing_ex/ | Good ex) http://kjy127.com/test-ex
    
  • 파일확장자는 URI에 포함하지 않는다. Bad ex) http://kjy127.com/photo.jpg | Good ex) http://kjy127.com/photo.jpg
    

• HTTP 응답 상태 코드 잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 리소스에 대한 응답을 잘 내어주는 것까지 포함이다.
  

200	클라이언트의 요청을 정상 수행
201	클라이언트의 리소스 생성 요청에 대해 정상 처리 (POST를 통한 리소스 생성 작업 시)
400	요청이 부적절 할 경우 (부적절한 이유를 응답 Body에 넣어줄 것)
401	클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때
403	클라이언트가 인증상태와 무관하게 응답하고 싶지 않은 리소스를 요청할 때 (400 사용을 권장)
404	클라이언트가 요청한 리소스가 존재하지 않을 때
405	클라이언트가 요청한 리소스에서는 사용 불가능한 메소드를 사용했을 때