REST API에 대해 공부한 것들을 정리
1. API
2. SOAP
3. REST, RESTapi, RESTful
1. API
먼저 API에 대해 알아야 restapi가 뭔지를 설명할 수 있을거라고 생각한다.
API는 Application Programming Interface의 약자로 소프트웨어 간의 지정된 형식으로 요청, 명령을 받을 수 있는 수단(Interface)이다.
(예로 한 응용프로그램이 자신이 갖고있는 정보를 전달하기 위해 어떤 방식으로 통신할 것인지에 대한 규격)
API는 정보를 갖고 있는 주체에서 만들기 때문에 API를 사용하기 위한 개발자는 어떤 방식으로 요청을 해야하는지 알 수 없기 때문에 API를 제공하는 입장에서 API 규격을 명시한 규격서를 참고해야한다.
또한 API는 형식이기 때문에 기술에 구애받지 않는다.
2. SOAP
REST API를 공부했는데 SOAP는 갑자기 왜 나왔냐
REST 형식이 SOAP의 단점을 해결해주기 때문이다. 그리고 알아서 나쁠건 없다고 생각한다.
그래서 SOAP는 Simple Object Access Protocol의 약자로 네트워크에서 http, https등을 통해 XML기반 메세지를 교환하는 프로토콜이다.
(XML과 JSON에 대한 정리도 추가하기)
SOAP의 목적은 SOA를 구현하기 위함이다.
SOA는 Service Oriented Architecture의 약자로 Service가 중심이 되는 소프트웨어 아키텍쳐이고, Service는 비즈니스적으로 의미가 있는 단위로 묶은것이다.
SOAP는 모든 데이터가 XML로 표현된다.
데이터들을 WDSL로 정의하면 UDDI에 등록하여 접근할 수 있도록 공개한다.
WSDL -> XML로 작성한 웹서비스를 기술한 언어
UDDI -> 웹서비스 저장소(중계 매개체 역할을 한다.)
WSDL(XML은 JSON보다 표현이 단순하지 않음 -> 무겁다)
웹은 누구나 어디서든 쉽게 접근할 수 있다는 장점이 있는데, UDDI를 사용해야만 서비스를 제공할 수 있다. 라는 한계점에서 REST라는 프로토콜이 아닌 소프트웨어 아키텍쳐 방법론이 나온다.
3. REST
위에서 설명한거 처럼 SOAP의 단점을 극복하기 위해 REST라는 개념이 나온다.
REST -> Representational State Transfer
일단 SOAP는 http통신 위에서 사용되는데 개발환경도 복잡하고 무겁고 인코딩 디코딩이 어렵고, 개발난이도가 높다는 등의 문제가 존재한다.
REST는 자원의 표현에 의한 상태를 전달한다.
자원의 표현 -> resource(데이터)의 이름
상태전달 -> 데이터가 요청되면 JSON 혹은 XML로 전달
SOAP가 SOA를 구현한다면 REST는 ROA를 구현한다.
ROA -> Resource Oriented Architecture로 중간매개체(UDDI) 없이 resource를 직접 주고 받는 아키텍쳐
REST라는 아키텍쳐 방법론은 3가지로 구성되어있다.
1. 자원 -> URI(이것도 URI,URL,URN 다시 정리해야겠다.)
2. 행위 -> http method
3. 표현 -> Representation
여러가지 특징이 있다.
1. 유니폼 인터페이스
지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일
2. 무상태성
클라이언트와 서버의 관계를 갖고(명확히 구분되어 있기 때문에 개발이 쉽고 확장성이 좋다.),
서버가 클라이언트의 상태를 보존하지 않음을 의미한다.
3. 캐시기능, 자체표현(API메세지만 보고 쉽게 이해할 수 있는 표현구조),
계층형구조(로드밸런싱, PROXY, 게이트웨이 등 네트워크 기반의 중간매체 사용가능)
http는 응답을 마치면 연결을 끊어버리는 성질을 갖고 있다.(stateless 무상태)
또한 http의 비연결성으로 인해 서버는 클라이언트를 식별할 수 없다.(connectionless 비연결성)
하지만 웹사이트들은 http환경에서 정보를 유지하고 있다 -> 쿠키, 세션을 이용함
REST API 디자인 가이드
1. URI는 정보의 자원을 명사로 표현해야한다.
예를 들어 로그인 기능이라면 localhost:8080/api/login 처럼 자원을 표현해야한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
3. 하이픈(-)은 가독성을 높이는데 사용하고 밑줄(_)은 사용하지 않는다.
4. 파일 확장자는 URI에 포함하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. has a의 관계를 표현할 때 /를 사용하고 id등 식별자를 사용할 때는{}로 감싸준다.
RESTful?
REST 방법론을 잘 따랐다면 RESTful하다고 할 수 있다.
이해와 사용을 쉽게 하기 위해 RESTful하게 만들어야한다.
REST의 한계
표준이 존재하지 않는다.
사용할 수 있는 메서드가 4개뿐이다.
REST를 지키기위해 method를 사용하다가 속도가 느려질 수 있다.(get은 post보다 빠름 body가 없으니깐)
그래서 GraphQL이라는게 나왔는데 다음에 공부하고 정리하겠다.
uri, url, urn 정리
XML, JSON 정리
