REST
SOAP
- Simple Object Access Protocol
- HTTP, HTTPS, SMTP등으로 XML 기반의 message를 전달하는 protocol
- RPC를 지원
- XML-RPC와 WDDX에서 envolope/header/body로 이뤄진 구조와 전송 개념을 도입
SOAP 구성
- SOAP envelope
- header와 body
- SOAP header (opt)
- actor(role): 어떤 중개자가 header entry를 처리할 것인지 지정
- mustUnderstand: 반드시 처리 필요 flag
- relay: 처리 못한 경우 forwarding 필요 여부
- SOAP Body
- SOAP Encoding Rule
-
SOAP RPC representation
- 현재는 SOAP 보다 REST를 주로 사용하여 설계함
REST
RESTful
- REST 형태의 architecture를 사용했다는 의미
- REST API를 제공하는 web service를 ‘RESTful’하다고 할 수 있음
- 공식 용어가 아님 (REST를 잘 적용해서 만들었다는 의미
- not RESTful ex.
- CRUD 기능이 모두 POTS로만 구성된 API
- route에 resource, id외의 정보가 들어간 경우 ex. (/students/updateName) <– update X
- route는 전체 경로(string)를 의미
REST
- REST (REpresentational State Transfer)
- WWW와 같은 Hypermedia system을 위한 software architecture의 한 형태
- 기존 HTTP protocol을 그대로 사용하기에 Web의 장점을 최대한 활용한 C/S architecture
- REST 특징
- resource를 이름으로 구분하여 식별
- ROA (Resource Oriented Architecture)
- state
- data 요청 시 상태도 전달 (JSON, XML 등 사용 가능)
- resource를 이름으로 구분하여 식별
- WWW와 같은 Hypermedia system을 위한 software architecture의 한 형태
REST pros/cons
- pros
- HTTP protocol 사용으로 인한 protocol 정의 cost가 없음
- HTTP로 동작하는 모든 platform에서 사용 가능
- cons
- 표준의 부재
- Method 종류의 제한 (4개)
- PUT, DELETE, putState 미지원 browser들이 있음
- REST 구성
- resoruce
- URI: resource 고유 ID
- /groups/:group_id
- URI: resource 고유 ID
- method
- GET, POTS, PUT, DELETE
- Representation of Resource
- 요청에 대한 응답 (representation)
- XML, TEXT, RSS< JSN 등의 다양한 형태 사용
- 요청에 대한 응답 (representation)
- resoruce
REST 특징
- CS 구조
- stateless
- HTTP protocol이 stateless이기에 REST 역시 stateless
- no session
- session과 cookie를 신경쓰지 않아도 됨
- server는 각 요청을 완전히 별개의 것으로 처리
- Cacheble
- HTTP의 cache 기능 사용 가능
- HTTP에서는 Last-Modified tag 혹은 E-Tag를 사용해 caching 구현
- HTTP의 cache 기능 사용 가능
- Layered architecture
- client는 REST API layer에만 의존
- API layer, business logic, load balancing, encryption 등의 layer 존재 가능
- Code-On-Demand
- server로부터 code script를 받아서 실행 가능
- Uniform Interface
- URI로 지정된 resource에 대한 일관된 interface로 동작
HTTP URI
- HTTP URI(Uniform Resource Identifier)
- resource 명시
- image, text db 등 모든 자원에 고유 ID인 HTTP URI 부여
- HTTP Method
- POST, GET, PUT, DELETE로 CRUD operation을 지원 (GDP2)
- GET: read : 정보 조회 용 (select)
- DELETE: delete
- POST: create
- PUT: update
-
head: HEAD <- header 정보 조회
GET ex. www.addr.com?key1=val1&key2=val2 ?뒤에 이어 붙여 서버로 전송 여러개의 경우 &를 delimiter로 사용 URL에 붙이는 방식이기에 대용량 전송이 어려움 (보안 취약) caching 되기에 POST 보다 빠름
POST는 값의 추가 목적이므로, query 용도가 아님 동일 GET request에 대해 동일 response를 받는 방법이 GET임POST ex. 갱신 목적 HTTP packet의 body에 넣어 전송 전송 data type 지정 필요
ex. default: application/octet-stream 단순 text의 경우: text/plain 파일 경우: multipart/form-data body 내 data를 넣어 전송하기에 대용량 데이터 전송에 접합 client (data encodnig) -> 전송 -> 서버 (data decoding) GET 보다 안전
- POST, GET, PUT, DELETE로 CRUD operation을 지원 (GDP2)
REST API desing rule
resource
- resource types
- document: DB의 record, object 유사 개념
- collection: server directory resource
- store: client에서 관리하는 resource storage
- URI
- noun, lower case 사용
- document의 경우 단수 명사
- collection/store의 경우 복수 명사
- GET/members/1
- HTTP methods
- DELETE /members/1
- POTS /members/2
REST API rule
- /로 계층 구분
- http://restapi.example.com/houses/apartments
- /는 중간 구분자로만 사용
- URI의 마지막에 ‘/’를 넣지 않음
- ’-‘ 추가 가능
- ‘_‘는 URI에 사용 금지
- URI 경로는 lowercase 사용
- RFC 3986(URI 문법 형식)은 URI schema와 host를 제외하고는 대소문자를 구별하도록 규정
- file 확장자는 URI를 포함하지 않음
- GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg
- resoruce간 연관 관계 존재 시
- GET : /uers/{userid}/devices
REST API design example
CRUD HTTP verbs Route resource 목록 표시 GET /resource resource 하나의 내용 표시 GET /resource/:id resource 생성 POST /resource resource 수정 PUT /resource/:id resource 삭제 DELETE /resource/:id
response code
- 1xx: 정보 교환
- 2xx: 요청 성공
- 3xx: 추가 동작 필요
- 4xx: 잘못된 요청
- 5xx: 서버 오류
ex.
GET /itemService? DepId=4450&...
client -----------------------------------> web service
<-----------------------------------
JSON: {"items": {"desc":"..."}, ...}
