8/17
- HTTP, SOAP, REST 학습
HTTP VS Socket
- 둘 모두 tcp/ip기반 통신
- Socket은 서버와 지속적으로 통신을 하면서 통신라인을 유지
- HTTP통신을 하게되면 클라이언트와 서버는 Request와 Response 때만 연결이 되고 그 후에는 연결을 끊어버림
- 따라서 웹서버는 다수의 사용자도 빠르게 처리할 수 있는 장점을 지님
SOAP
- SOAP(Simple Object Access Protocol)는 XML을 전송하는 방식
- HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 메시지를 교환하기 위한 통신규약 프로토콜
- SOAP는 떨어져 있는 서버에게 함수호출이나 객체반환을 통해 원하는 값을 반환 받는 RPC방식
* RPC(Remote Procedure Call)
- 다른 네트워크에 있는 컴퓨터에게 서비스를 요청하는 프로토콜
SOAP 동작 순서
- 서버는 WSDL을 UDDI라는 저장소(Service Registry)에 저장합니다.
- 클라이언트에서 서버로 SOAP통신하기 위해서는, 사전에 서버로부터 WSDL 파일 혹은 URL을 제공받아야 함
- 사용자는(Service Consumer) UDDI에 접근해 자신이 원하는 서비스를 누가 제공하는지 WSDL을 찾습니다.
- 사용자는 원하는 WSDL을 다운받은 후 양식에 맞게 SOAP를 작성하게 됩니다.
- SOAP또한 XML을 사용하여 인코딩 되게 되며 다음과 같이 만들어집니다.
- SOAP Part : HTTP Header, SOAP Envelope/Header/Body 등
- 그 외 Attachment 부분
- Envelope안에는 GET or POST를 넣어 자료를 어떤식으로 처리할지 보내게 됩니다.
- 그럼 서버는(Service Provider) 클라이언트에서 받은 자료를 바탕으로 서비스를 제공하게 됩니다.
* WSDL
- XML형태로 만들어져 있으며
- 데이터 타입, 메서드의 인자와 리턴 값, 인터페이스 정의 및 메서드 선언 등을 저장
- 추상정보와 구체정보를 분리하여 저장하고 있어서 추상정보의 재사용이 가능
SOAP 장점
1. 프록시와 방화벽에 제약이 없다. (기존 HTTP방식을 사용함으로)
2. 플랫폼과 프로그래밍에 독립적이다. (WSDL이라는 양식을 토대로 작성해서 보내줌으로)
3. WSDL, UDDI 등 표준 통신규약이 있다.
4. 분산 환경에 적합하다.
5. 기존의 컴포넌트보다 이기종간 상호운용성이 높음
6. stateful방식이다.(서버는 세션을 저장하여 클라이언트와 통신하게 됩니다.)
SOAP 단점
1. 너무 복잡하다.
2. 해당 문법을 작성하기 위해선 Tool이 필요하다.
3. 무겁고 느리다.
4. 작성하는것 또한 어렵다.
REST VS SOAP
- REST 방식은 SOAP에 비해 작성하기 매우 간단함
- 손쉬운 사용, 범용성 등에서 이점
- 웹서버에서 RESTful 방식 채용
- REST 방식에서 서버는 클라이언트의 요청에 대비해 API를 작성하고, 그 후 클라이언트의 요청이 있을 때 마다 해당 API에 대한 데이터를 보내줌
REST
1. Uniform interface
- 일관적인 인터페이스로 구성되어야 합니다.
- 즉, 어떤 플랫폼이건(Android, rinux, IOS 등...) URI를 통한 접근이 가능해야 합니다.
2. Stateless
- 서버는 클라이언트의 상태를 알 필요가 없다. 즉, 세션유지를 하지 않습니다.
- Rest는 HTTP통신으로 클라이언트의 요청이 있을 때 해당 자료만 건내주면 되기 때문입니다.
- 따라서 클라이언트가 몇번 접속했고, 클라이언트는 최근 어디까지 데이터 요청을 했던 서버는 알 필요가 없습니다.
3. Cacheable
- Rest는 기본적인 HTTP 통신을 사용합니다. 즉, 기본적인 웹 통신에서의 캐시를 사용할 수 있습니다.
- 대표적인 예로 인터넷에 접속하면 이미지나 문서들은 클라이언트 캐시에 저장되고 동일한 요청이 일어나면 서버에서 다시 받아오는것이 아닌 캐시에서 꺼내다 사용합니다.
- 때문에 서버의 부하를 줄이고 속도를 증가시키는 효과를 가져올 수 있는데 이 특징은 HTTP통신에서 가능합니다.
4. Client - Server 구조
- 클라이언트와 서버의 역할을 확실하게 나눠야 합니다.
- 즉, 서버는 API만을 제공하며, 클라이언트는 로그인 정보, 세선같은 것들을
잘 관리해야 합니다.
5. 계층화(Layered System)
- 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없습니다.
- 클라이언트는 그냥 서버로부터 데이터만 받으면 되기 때문입니다.
- 따라서 서버로 가는 경로마다 로드벨런스나 공유 캐시 등을 넣어 시스템 규모 확장에 유용합니다.
6. Code On Demand(optional) : "바로 실행 가능한 코드"
- REST는 서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 한다.
- 이것은 사전 구현에 필요한 기능의 수를 줄임으로써 클라이언트를 단순화합니다.
- 즉, 평소에 우리는 정적인 데이터를 xml 또는 json에 담아서 client로 보내고 client가 이것을 가공합니다.
- 하지만 code on demand라는 것은 client에 보내는 데이터를 "바로 실행 가능한 코드"를 보내서 이것을 Client에서 실행하는 것을 말합니다.
- 그러나 가시성도 저하되므로 REST 내에서 선택적 제한 사항입니다.
REST 규칙
1. 모든 정보는 URI로 표현한다.
- GET을 하던 POST를 하던 DELETE를 하던 같은 데이터의 URI경로는 동일해야 합니다.
- ex) GET school/class, POST school/class, DELETE school/class
2. 계층관계를 표현할 땐 '/'를 사용합니다.
3. 언더바( _ ) 을 사용하지 않고 하이픈( - ) 을 사용합니다.
- 언더바를 사용하 경우 주소창에 문자가 가려지거나 사용자가 읽을 때 가독성이 떨어질 수 있기 때문입니다.
4. 띄어쓰기 금지.
- 띄어쓰기 또한 가독성을 떨어뜨려 사용자로 하여금 햇갈리게 할 수 있습니다.
5. URI의 표현은 소문자로.
6. URI에 확장자를 표시하지 않는다.
7. URI의 표현은 명사로 한다. 즉, 동사로 하지 않는다.
- ex) GET school/class //OK, GET school/study //Fail
8. URI 끝에 '/'를 붙이지 않는다.
- ex) GET school/class //OK, GET school/class/ //Fail
REST 장점
1. XML, JSON, RSS 모두 지원한다.
2. HTML의 from method인 GET, POST를 인용한다.
3. 굉장히 직관적이며 GET, POST, PUT, DELETE 4가지를 이용해 모든 처리를 완벽하게 할 수 있다.
4. DB를 사용할 때도 REST의 키워드는 매칭이 잘 된다.
5. stateless방식을 사용하며 단순하고 속도가 빠르다.
* REST from method
GET - 서버로 부터 정보를 얻어올 때 (Read)
POST - 서버(DB)에 무언가를 생성하고자 할 때 (Create)
PUT - 서버(DB)를 수정할 때 (Update)
DELETE - 서버(DB)의 내용을 지울 때 (Delete)
