REST API 디자인 가이드 URI는 정보의 자원을 표현해야 한다. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다. 중심 규칙 사용자 추가, 삭제, 수정을 하는 REST API를 설계해보자. URI는 정보의 자원을 표현해야 한다. (리소스는 명사를 선호) GET /members/delete/1아이디가 1인 계정을 삭제하라는 뜻 같다. 이것은 REST 할까? REST하지 않다. URI는 자원을 표현하는데 중점을 두어야 하며, delete같은 행위에 대한 표현이 들어가면 안된다. 위의 URI는 아래와 같이 수정할 수 있다. DELETE /members/1HTTP Method 그렇다면 회원을 추가하거나 정보를 조회하는 것을 설계해 보자. 회원정보 조회 GET ..
2019/05/18
[들어가기전] REST API라고하면, 데이터를 json으로 주고받고 행위에 맞게 HTTP Method를 셋팅해주는 것으로만 알고 있었다.(동영상 보기전까지) 몇 달전에 스프링을 이용한 RESTful 웹 서비스 구축하기 책을 보며 프로젝트를 따라해보았는데, 책의 마지막부분 쯤에 HATEOAS라는 부분이 있었다. spring에서 제공해주는 것인데 링크를 만들어주는 라이브러리 였다. REST API 구축하는데 이게 왜 들어가있지라는 궁금증을 갖긴 했었는데 이 동영상을 보고나니 그 궁금증이 풀렸다. 결론적으로 말하자면, 우리가 얇게 알고 만들었던 REST한 API는 사실 REST API가 아닐지도 모른다. 그저 HTTP API라고 불러야 하며 REST API는 여러가지 제약조건을 만족시켜야 한다. REST R..
