REST는 네트워크 아키텍쳐 원리의 모음이다.(위키)
사람들이 네트워크 아키텍쳐를 짤때 이렇게 짜자고 약속한 모음집 같은거라고 보면 된다.
REST 에 적용되는 제한은 다음과 같다.
일관적인 인터페이스로 분리되어야 하고
각 요청 간 클라이언트의 context가 서버에 저장되면 안되고
캐시 처리가 되어야 하고
계층화가 되어야 하고
아키텍쳐를 단순화 시켜 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있어야 하며
서버에서 코드를 client로 보내서 실행할 수 있어야 한다.(optional)
위의 내용조차 REST에 대한 정말 간략하고 요약된 내용이며, REST의 목적이라 하면
유지보수가 편리하고 쉽게 알아먹을 수 있으며 확장성이 좋은 코드를 짜라
즉 좋은 코드를 짜는 지침서 같은거라 보면 되겠다.
왜 이런말을 하는건지 궁금해 하는 사람들이 있을것이다.
그건 약 1달전에 발생한 궁금증 때문이다.
다음 2가지를 잘 생각해보자.
??
뭔가 이상하지 않은가?
REST를 잘 이해하고 HTTP에서 말하는 멱등성이라는게 무엇인지 정확하게 파악하는사람이라면 왜 아닌지 설명이 가능할 것이고
아니라면 그런가? 싶을것이다.
위키에 나오는 HTTP 요약표는 다음과 같다.
POST를 쓰더라도 데이터 변형이 일어나지 않을수도, GET 방식을 쓸때 데이터 변형이 일어날 수 있다.
하지만 HTTP는 REST와 같이 양식과 규칙의 체계이다.
즉 사람들이 '이렇게 씁시다' 라고 규칙을 정해서 쓴다는 것이다.
작정하고 쓴다면 GET의 url 파라미터에 데이터를 집어넣고 억지로 데이터 변형을 시킬수도, POST의 payload에 아무것도 넣지 않아서 데이터 변형이 일어나지 않을 수도 있다.
하지만 그렇게 할수는 있는데
그렇게 쓰지 말라고 하는거다.
즉, 당신의 코드를 처음보는사람이 GET 함수를 봤을때, 이 코드를 발송하면 데이터 변형이 일어나지 않겠구나! 라고 생각을 한다는 것이고, 당신이 GET으로 데이터를 억지로 변형시킨다면 그건 안좋은 코드라는 것이고, POST함수를 용도대로 데이터 변형을 위한 요청으로 사용한다면, 잘 사용하고 있다는 것이다.
REST와 마찬가지로, '좋은코드'를 짜기 위한 방향성이라고 생각하면 되겠다.