REST API
REST API를 공부하면서 이응준님의 "그런 REST API로 괜찮은가"를 참조 했다.
https://tv.naver.com/v/2292653
REST API란 지금까지 client가 api요청을 보내면 그 값을 JSON , XML로 반환해주는 api정도?? 로만 인식하고 있었다. 영상을 들어보니 REST API라는 말이 맞을 수도 있고 틀릴 수도 있다는데 REST API를 만든 로이필딩씨께서는 self-descriptive messages , HATEOAS 를 충족하지 못하면 REST API아니라고 한다....?
REST API이기 위한 몇가지 조건이 있다.
Unifrom Interface의 제약조건
identification of resources
* resource가 uri로 식별되면 된다. (ex : api/users/name 이런식으로 uri상에서 정보가 나타야한다는것 같다.)
manipulation of resources through representations
* representation전송을 통해서 resource를 조작해야 한다. (GET, POST, UPDATE ...)
ex) POST요청인데 데이터를 삭제하는 요청은 없어야한다.
self-descriptive messages
* 메시지는 스스로를 설명해야 한다.
GET / HTTP/1.1
- 이 HTTP 요청 메시지는 뭔가 빠져있어서 self-descriptive하지 못하다.
GET / HTTP/1.1 Host : www.example.org
- 목적지를 추가하면 이제 self-descriptive 하다라고 말할 수 있다.
HTTP/1.1 200 OK [ {"op" : "remove", "path" : "a/b/c/"} ]
- self-descriptive하지 못하다. 어떻게 해석해야할지 모르기 때문이다.
HTTP/1.1 200 OK Content-Type : application/json [ {"op" : "remove", "path" : "a/b/c/"} ]
- 대괄호, 중괄호의 의미가 뭐인지 이해할 수 있기 때문에 파싱이가능해지고 문법을 해석할 수 있게 된다. 하지만 이것만으로는 부족한데 여기서 의미하는 "op"와 "path"의 의미를 모르기 때문이다.
HTTP/1.1 200 OK Content-Type : application/json-patch+json [ {"op" : "remove", "path" : "a/b/c/"} ]
- json patch + json이라는 미디어 타입으로 정의되어 있는 메시지 이기 때문에 json patch라는 명세를 찾아가서 이것을 이해한다음에 메시지를 해석하면 올바르게 이 메시지의 의미를 해석할 수 있음
- 메시지 내용으로 온전히 해석이 가능해야한다.
hypermedia as the engine of application state(HATEOAS)
- HATEOAS : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
HTTP/1.1 200 OK Content-Type : text/html <html> <head></head> <body><a href="/test">test</a></body> </html>
- html 같은 경우는 a link 로 연결 되어 있기 때문에 HATEOAS를 만족한다.
HTTP/1.1 200 OK Content-Type : application.json Link : </articles/1>; rel="previous", </articles/3>; rel="next"; { "title" : "The second article", "contents" : "blah blah ..." }
- json 같은경우도 LINK를 이용해서 URI 정보를 인지할 수 있다
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-hateoas</artifactId> </dependency>
- spring 에서는 다음과 같은 hateoas설정을 도와주는 의존성이 존재한다.
- 사용법 : https://velog.io/@max9106/Spring-Boot-HATEOAS
혼동된 개념 정리
- URI 와 URL의 차이점
URL ( Uniform Resource Locator)
* 자원
* 예전에는 URL이 가르키는게 파일 소스
* 요즘은 Rewrite등의 아파치,톰켓등의 핸들러 때문에 자원이라고 부름
* 웹사이트 주소가 요청하는 파일이라기 보다는, 구분자로 보는 것
* 웹 상에 서비스를 제공하는 각 서버들에 있는 파일의 위치를 표시하기 위한 것
- http://blong.com/work/test.pdf 는 blog.com서버에서 work폴더안의 test.pdf를 요청
URI ( Uniform Resource Identifier)
* 통합 자원 식별자
* 인터넷에 있는 자원을 나타내는 유일한 주소이다.
* URI의 존재는 인터넷에서 요구되는 기본조건으로서, 인터넷 프로토콜에 항상 붙어다님
- ex) http://www.naver.com (http프로토콜임을 명시하고 있음)
* URI의 하위개념에 URL,URN이 포함되어 있다.
* URI의 보편적인 형태가 URL인데, URI의 부분집합으로 볼 수 있다.
- 자원에 접근하기 위해 사용되는 절차
* 어떤 자원을 가지고 있는 특정한 컴퓨터
* 컴퓨터 상의 유니크한 자원의 이름(파일명)
* http://test.com/test.pdf?docid=111 이라는 주소는 URI이지만 URL은 아니다.
- http://test.com/test.pdf 까지만 URL임(주소의 위치)
* docid=111이라는 쿼리스트링의 값에 따라 결과가 달라지게됨, 따라서 식별자 역할을 하고 있음
* http://test.com/test.pdf?docid=111 ,http://test.com/test.pdf?docid=112는 같은 URL을 가지고 다른 URI를 가짐
URN (Uniform Resource Name)
* 위치와 상관없이 리소스의 이름값을 이용해서 접근하는 방식
* 노출된 URL은 http://blog.com/syun/222 인데, http://blog.com/syun/list/323으로 요청을 보내면 404 response를 받는다. 이를 보완하기 위해서 위치 정보와는 무관하게 리소스를 찾을 수 있게 해주는 방식임
* 해당 리소스의 위치정보가 아닌 실제 리소소의 이름으로 사용하는 방식
* 정리
*
* URI에는 URL,URN이 포함되어 있다. URL은 URI이지만, URI는 URL이 아니다.
* URL은 인터넷 상의 자원 위치를 나타냄
* URI는 인터넷 상의 자원을 식별하기 위한 문자열의 구성
출처 : https://cornswrold.tistory.com/286
출처 : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
출처 : https://velog.io/@pa324/개발상식-URI-URL-차이-정리
'개인공부' 카테고리의 다른 글
| 병렬처리 (0) | 2020.09.28 |
|---|---|
| CSRF , CORS (0) | 2020.09.02 |
| IP란? (0) | 2020.08.19 |
| Path with "WEB-INF" or "META-INF" 오류 (0) | 2020.08.15 |
| spring boot mybatis (0) | 2020.08.14 |
