API는 메뉴판이라고 생각하고 설계하자.
명확하고 일관된 API 설계하기 : REST API
REST는 Representational State Transfer 의 약어로 하이퍼 미디어를 전송하는 규칙!
REST의 6 원칙과 제약
조금 더 자세한 설명은 여기에
1. uniform interface 일관성
2. client-server 구분
3. Stateless : 작업에 대한 요청의 상태 정보를 저장하거나 관리 하지 않는다. 요청끼리 서로 의존성이 있으면 안된다.
4. Cacheable : 요청은 캐싱이 가능해야한다.
5. Layered System : 요청 하나는 최종 응답 전에 각 계층의 정보를 얻을 수 없도록 분리되어 계층화돼야된다.
6. Code on Demand : 서버는 유저에게 실행 가능한 코드를 보내줄 수 있다.
네이밍
엔드포인트일 경우 주로 동사형태로 네이밍을 하지만 restful URI(uniform resource identifier)의 경우 문서, 컬렉션, 스토어, 컨트롤 4가지 범주로 자원을 분류하여 어떤 범주에 속하는지에 따라 명사로 네이밍을 한다.
그 외 추가
- URI 마지막에
/를 사용하지 않는다. _언더스코어 대신-하이픈을 사용해 가독성을 높인다.- 소문자를 사용한다.
- 파일의 확장자는 사용하지 않는다.
- CRUD 메서드를 사용하지 않는다.
- 자원의 필터링은 쿼리 파라미터를 사용한다.
- 한 API에서 하나의 정보만 요청하도록 한다.
API 종류
- public API
- private API
- Partner API
모든 프로그램은 API를 가질 수 있다.
- Windows API : 윈도우 운영체제 기능들을 사용가능
- Database 관리 프로그램 API : DB 입출력 기능들 사용가능
- 어떤 프로그램 API : 프로그램이 존재한다면 API도 존재. 어떤 프로그램(chatGPT, 파파고 등등)의 기능들을 사용 가능
API 판매하는 플랫폼
- 네이버 클라우드와 같은 사이트에서 다양한 API를 무료 또는 구매하여 사용 할 수 있다.
- APT 마켓 플레이스 "사이트 바로가기"와 같은 곳에서 내가 잘 만든 API를 판매할 수 있다.
API 만들어서 팔아보쟈구
