Http 요청의 종류, 메서드
- 데이터 조회: GET
- 데이터 추가: POST
- 데이터 수정: PUT
- 데이터 삭제: DELETE
Request의 구성
- Head: Request에 대한 부가 정보(headers)를 담고 있는 부분(ex. 메소드)
- Body: 실제 데이터를 담고 있는 부분
보낸 요청에 대해서 확인하기 위해서는 개발자 도구의 Network 탭을 보면 Header, body 등의 data를 볼 수 있다.
Web API
- API(Application Programming Interface): 개발할 때 사용할 수 있도록 특정 라이브러리나 플랫폼 등이 제공하는 데이터나 함수 등
- Web API: 서비스에서 사용될 모든 URL마다 request에 대한 처리와 response를 미리 정해놓은 규격
REST API: RESTful한 API
- REST(REpresentational State Transfer)ful architecture: 상태 이전 표현에 있어서 가장 표준적인 구조
- 기준
1) Client-Server: client와 server의 역할이 분리되어야 함
2) Stateless: 각 request에 대해 어떤 맥락(Context)도 저장하지 않음
3) Cache: Cache를 활용해서 네트워크 비용을 절감해야 함
4) Uniform Interface: Client가 Server와 통신하는 Interace가 준수해야 하는 하위 조건
5) Layered System: Client와 Server 사이에는 프록시(proxy), 게이트웨이(gateway)와 같은 중간 매개 요소를 두고, 보안, 로드 밸런싱 등을 수행할 수 있어야 함(hierarchical layers들이 형성됨)
6) Code On Demand: Server는 받아서 바로 실행할 수 있는 applet이나 script 파일을 Client로 보내야 함
Uniform Interface
- identification of resources: resources를 URI(Uniform Resource Identifier)로 식별할 수 있어야 함
- manipulation of resources through representations: Client와 Server 둘 다 직접적으로 resource를 다루는 게 아니라 리소스의 표현(representations)을 다뤄야 함
- self-descriptive messages: Client의 request와 Server의 response 모두 그 자체이 있는 정보만으로 모든 것을 해석할 수 있어야 함
- hypermedia as the engine of application state: 분산 하이퍼미디어 시스템(Distributed Hypermedia System)에 적합하도록, Server의 response에는 현재 상태에서 다른 상태로 이전할 수 있는 링크를 포함하고 있어야 함
identification of resources
- URL은 리소스를 나타내기 위해서만 사용하고, 리소스에 대한 처리는 메소드로 표현해야 함
- document는 단수 명사로, collection은 복수 명사로 표시함
