API (Application programming interface)
응용프로그램이나 서비스를 개발하는데 필요한 운영체제(OS)나 라이브러리 등의 특정 기능을 추상화하여 사용하기 쉽도록 만든 인터페이스다.
뭔말알? 쉽게 비유해보자면 API는 식당 메뉴판이다. 당신이 오덕 메이드 카페를 갔다. 가서 메뉴판을 보고 으쌰으쌰 오므라이스를 주문했다. 그럼 주방에서 으쌰으쌰 오므라이스를 만들어서 당신에게 줄 것이다.
이처럼 API는 특정 서비스를 제공하기 위한 프로그래밍 세트로 사용할 수 있는 프로그래밍 인터페이스 목록이 있고 호출하여 사용한다. 가령 웹 앱을 구현하는데 네이버 로그인을 해야되는 상황이라 치자. 그럼 네이버에서 제공하는 OpenAPI를 통해 네이버의 로그인 기능을 호출하여 연동할 수 있는 것이다.
OpenAPI
오픈 API 또는 공개 API는 개발자라면 누구나 사용할 수 있도록 공개된 API를 말하며, 개발자에게 사유 응용 소프트웨어나 웹 서비스의 프로그래밍 적인 권한을 제공한다.
public API, 즉 모두에게 공개되어 누구나 갖다 쓸 수 있는 API라는 얘기다.
API 종류
API는 접근 권한에 따라 세가지로 분류할 수 있다. 사실 종류라기 보단 접근지정자에 해당하는 내용이다.
1. private API
내부 API로, 외부에 노출되지 않는다. 자체 제품과 서비스를 개선하기 위해 내부적으로 사용하는 것이 일반적이다. private API로 발행하고 중간에 gateway를 두고 사용하는 경우도 있다.
2. public API
public API는 개방형 API로, 모두에게 공개되는 API 형태다.
3. partner API
partner API는 인가된 사용자에 한하여 공유되는 API로 비즈니스 관계에서 사용되는 편이며, 종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용된다.
REST (REpresentational State Transfer)
REST는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
쉽게 말해 API를 구축할때 URI와 HTTP Method를 활용하여 API의 기능을 추측 가능하게끔 아키텍쳐를 구성하는 원칙같은 것이다. REST 원칙을 잘 따른 API만이 RESTful API라는 영광을 얻을 수 있는 것이다. 아 이 API는 RESTful하구나~ 하는 것이란 얘기다.
REST 구성 요소
1. 자원 (Resource) - URI
모든 리소스는 고유한 주소가 존재하고, 서버에 존재한다. 우린 URI를 통해 리소스를 구분하고 호출한다.
2. 행위 (Verb) - HTTP Method
웹에서 일어나는 행위는 뻔하지 않은가? CRUD를 말하는 것이다. 그에 맞게 HTTP Method를 설정해주면 된다.
| HTTP Method | 설명 |
|---|---|
| POST | CREATE 작업에 대한 Method로 주로 서버에 데이터를 추가할 때 사용한다. |
| GET | READ 작업에 대한 Method로 주로 서버에서 데이터를 읽어올 때 사용한다. |
| PUT | UPDATE 작업에 대한 Method로 주로 서버 데이터의 갱신을 위해 사용한다. (대상 데이터가 전체일 때) |
| PATCH | UPDATE 작업에 대한 Method로 주로 서버 데이터의 갱신을 위해 사용한다. (대상 데이터가 일부일 때) |
| DELETE | DELETE 작업에 대한 Method로 주로 서버 데이터의 삭제을 위해 사용한다. |
3. 표현 (Representation of Resource)
브라우저와 웹 서버간 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등있다. JSON, XML을 통해 데이터를 주고 받는 것이 일반적이다. 그냥 JSON쓰자. 이게 짱이다.
REST 특징
1. 서버-클라이언트 구조 (Server-Client)
서버와 클라이언트 구조를 띈다는 건데 이건 웹 서비스면 공통아닌가? 이걸 특징이라고..
2. 무상태 (Stateless)
HTTP 프로토콜을 사용하기 때문에 HTTP의 특징인 무상태성을 갖는다. 이건 이 글을 확인해보길 바란다. HTTP-Request/Response
3. 캐시 처리 가능 (Cacheable)
HTTP 프로토콜에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 지원한다. 이것도 HTTP 특징이라..
4. 계층화 (Layered System)
클라이언트, 서버로만 구성할 수 도 있고 중간에 Gateway나 프록시 서버와 같은 미들 웨어를 배치해 계층화할 수 있다는 얘기다.
5. 인터페이스 일관성 (Uniform Interface)
URI로 지정한 리소스에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다.
6. 자체 표현 (Self-Descriptiveness)
URI만 분석해도 무슨 기능인지 유추가 된다는 특성이다.
REST 장단점
장점
- HTTP 인프라 베이스라 REST API를 위한 인프라를 구축할 필요가 없다.
- HTTP 표준을 따르기 때문에 여러 추가적인 기능을 사용할 수 있다.
- HTTP를 지원하는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API URI가 의도하는 바를 명확하게 나타내므로 기능을 쉽게 파악할 수 있다.
- 기능 통합으로 여러 서비스를 통합할 때 생기는 디자인 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
단점
- 표준 자체가 존재하지 않아 정의가 필요하다. (그니깐 하기 나름이다.)
- HTTP Method 형태가 제한적이다. (GET, POST, PUT, PATCH, DELETE)
- 테스트에 있어 전문성을 요구한다. (Header, dataType 등 HTTP 부가정보 설정)
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다. (구형 IE 버려라 좀)
REST API
REST 원칙을 기반으로 구현된 API를 말하며 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 형태를 말한다.
그니까 그냥 API 호출 URI만 분석해도 이게 뭐하는 놈이겠구나~ 하고 예측이 가능한 형태가 REST API라 할 수 있다.
REST API 설계 규칙
규칙이라기 보단 권고 사항 정도가 되겠다.
1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
🤮 BAD - https://velog.io/@carrotsman91/putShit/
😀 GOOD - https://velog.io/@carrotsman91/shit/2. 마지막에 슬래시(/)를 포함하지 않는다.
🤮 BAD - https://velog.io/@carrotsman91/putShit/
😀 GOOD - https://velog.io/@carrotsman91/shit3. 언더바(_)대신 대시(-)를 사용한다.
🤮 BAD - https://velog.io/@carrotsman91/carrots_shit
😀 GOOD - https://velog.io/@carrotsman91/carrots-shit4. 행위를 포함하지 않는다.
🤮 BAD - https://velog.io/@carrotsman91/delete-carrots/1
😀 GOOD - https://velog.io/@carrotsman91/carrots/15. 파일확장자는 URI에 포함하지 않는다.
🤮 BAD - https://velog.io/@carrotsman91/carrotsShit.jpeg
😀 GOOD - https://velog.io/@carrotsman91/carrotsShitRESTful
REST의 원리를 따르는 시스템을 의미하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있다.
규정집이라도 있나보다~ 하하. 솔직히 이 칭호를 얻는게 무슨 의미인지 모르겠다. 상이라도 줄건가?
SOAP (Simple Object Access Protocol)
일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.
REST를 설명할 때 가끔쓰 SOAP에 대한 얘기가 나와 정리해봤다. 일단 이 두놈이 비교대상이 될 수 없는게 REST는 개발 원칙같은 것이고 SOAP은 프로토콜이다. 일단 SOAP 자체는 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜이다. 한마디로 JAVA 프로그램에서 C# API를 호출해서 쓴다 이렇게 요약할 수 있겠다. 근데 텍스트만 봐도 알 수 있듯 겁나 무겁고 설정해줘야되는 표준이 많다. 번잡스러운 녀석..
정리하며
REST와 REST 원칙을 적용한 API, 모범적으로 준수한 RESTful에 대해 알아봤다. 추가로 SOAP에 대해 간만 봤는데 얘는 나중에 자세히 다루겠다. 결론적으로 요약하자면 그냥 RESTful이라는게 어떤 특정 구현체가 아니라 REST 원칙을 준수하게 따랐는지에 대한 플래그 쉽이다.
오늘 저녁은 간짬뽕이다. 🥕
참고 : https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://dev-coco.tistory.com/97#REST-REpresentational%--State%--Transfer-%EB%-E%--%-F
오덕 메이드카페를 상당히 잘 아시네요