반응형
0. API
1. REST API
2. RESTful API
3. get vs post
0. API
- 프로그램 간 상호작용 촉진, 정보교환
- 호출(client) > 응답(server)
- 규격: JSON, XML, HTML 등
- application 분리
1. REST API(Representational State Transfer API)
- REST 기반으로 API 구현
- 최근 open API의 대부분이 REST API 형식
- micro 서비스, 하나의 Application을 작은 단위로 쪼개어 통합하여 구현
- 시스템 분산 > 확장성, 재사용성 ↑ > 유지보수 및 운용, 운영의 편리성 ↑
- HTTP 표준으로 구현
설계 기본 규칙
- 도큐먼트: 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
- 컬렉션: 서버에서 관리하는 디렉터리라는 리소스
- 스토어: 클라이언트에서 관리하는 리소스 저장소
REST API 설계 규칙
- 슬래시 구분자"/"는 계층관계를 나타내는데 사용
- 마지막 문자로 슬래시"/"를 포함하지 않음
- 하이폰"-"은 URI 가독성을 높이는데 사용
- 밑줄"_" 사용하지 않음
- URI 경로 소문자 사용, 대문자 사용하지 않음
- 파일확장자 포함하지 않음
구성 요소
- 자원(Resource) - URI
- 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재함
- 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI임
- Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청함
- 행위(Verb) - Method
- HTTP 프로토콜의 Method를 사용함
- HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공함(CRUD)
GET Read : 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청한다. POST Create : 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보낸다. PUT Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 전체를 바꿀 때) PATCH Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 일부만 바꿀 때) DELETE Delete : 정보 삭제, (안전성 문제로 대부분 서버에서 비활성화한다.)
- 표현(Representation of Resource)
- Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등
- JSON, XML을 통해 데이터를 주고 받는 것이 일반적임
2. RESTful API
- REST 아키텍처를 구현하는 web service를 나타내는 용어
- REST 원리의 시스템 > RESTful
목적
- REST API 구현
- API의 이해도 및 호환성을 높이는 것이 주목적, 성능이 주목적이 아님
3. get vs post
| GET | POST | |
| 캐시 | ㅇ | X |
| 브라우저 기록 | ㅇ | X |
| 북마크 추가 | ㅇ | X |
| 데이터 길이 제한 | ㅇ | X |
| HTTP 응답 코드 | 200(Ok) | 201(Created) |
| 언제 주로 사용하는가? | 리소스 요청 | 리소스 생성 |
| 리소스 전달 방식 | 쿼리스트링 | HTTP Body |
| idempotent | ㅇ | X |
- idempotent: 동일한 연산 적용 > 동일한 결과
- non-idempotent: 동일한 연산 적용 > 다른 결과
동일한 모델을 적용하여 다른 결과가 나오는 모델의 연산 적용이 들어간다면 "POST"를 써야함
ref
