REST - REST 좋아하시네

Posted on 2017-06-12 Edited on 2018-02-13 Disqus:

연재 목록

RESTful APIs, the big lie

이제 개발자들 사이에 널리 퍼진 REST에 대한 오해를 들춰볼 차례이다.

독자 입장에선 이 정성으로 그냥 논문을 읽지 그러냐는 의문도 들 수 있겠지만,

이 바닥의 수많은 오해를 발견하는 재미도 있었다.

REST에 관한 끊이지 않는 논쟁

자신을 “SPA (UI/UX/server) architect and author”라고 소개하고 있는
Michael S. Mikowski의 RESTful APIs, the big lie라는 자극적인 글과 댓글을 읽고 한번 정리해볼 필요가 있다고 생각했다.

댓글로 달려드는 모두가 REST나 API를 바라보는 관점이 다르고, 댓글을 읽으면서 ‘그래, 그렇지’하면서 나의 관점도 계속 흔들렸다.

내가 흔들렸던 이유는 이 글을 읽을 때는 막 REST에 대해 공부하기 시작했을 때였기도 했고, RESTful한 API를 만들기 위한 현실적인 고민들이 남일 같지 않았기 때문이기도…

그냥 REST라는 용어만 포기하면 편하다는 결론은 내 후속 블로그 글에서 다시 확인하시고, 일단 개싸움부터 들여다보자.

사실 블로그 자체는 REST를 이해하는데는 별로 도움이 안 되는 글이긴 한데, 이런 개싸움이야 말로 진짜 현실 세계(반 REST 진영이 가장 많이 언급하는 단어가 ‘real world’이다)의 문제인 듯!

주요 논점을 정리해보고, 딸린 댓글을 개발 새발 정리한 버전은 페이지 마지막에 붙여놓겠다.

블로그 본문

우선 블로그에서 저자가 주장하는 바를 짧게 정리해보자.

Problem #1: There is little agreement on what a RESTful API is

HTTP 메소드와 응답코드는 모호해서 그 뜻이 정확히 뭘 의미하는지 사람마다 다르게 인식한다.

어떤 응답코드를 줄 지는 회사/사람마다 다른 기준이 있을 수 있어서, client 입장에선 정확히 예측하기 어렵다.

Problem #2: The REST vocabulary is not fully supported

브라우저는 PUT과 DELETE같은 문법을 지원하지 않는다.

307 Temporary 같은 애들은 브라우저마다 상이하게 처리되기도 한다. 제대로 지원하는 건 200과 500뿐이다.

Problem #3: The REST vocabulary is not rich enough for APIs

HTTP의 문법은 풍부하지 못해서 모든 어플리케이션의 요청과 응답을 표현할 수 없다.

Problem #4: RESTful APIs are very hard to debug

그래서 REST로 통신할 때 문제가 생기면 7가지나 되는 조합으로 원인을 파악해야 한다.

HTTP method (GET/POST)
URI
실제로 사용하고 싶은 HTTP method (PUT/DELETE..) in payload
진짜 메시지 in payload
응답코드
진짜 받아야 하는 응답코드 in payload
진짜 메시지 in payload

이런 한계 때문에 어떤 문제가 발생했을 때, 디버깅을 위해 고려해야할 게 너무나 많다.

Problem #5: RESTful APIs are usually tied to HTTP

HTTP에 너무 종속되어 있다.
HTTP가 아닌 다른 전송 방식으로 전환하려면 또 저 7가지 조합을 고려해서 만들어야 한다.

The way forward: JSON-Pure APIs

그래서 제안하는 건, JSON-Pure APIs

이 글이 쓰인 지 3주 후 JSON-Pure APIs에 관한 후속 블로그가 올라온다

논쟁

블로그 본문과 댓글에서 발화한 여러 논쟁을 크게 묶어 정리해본다.

HTTP 메소드와 응답코드는 모호해서 그 뜻이 정확히 뭘 의미하는지 사람마다 다르게 인식한다.

따지고 보면 그걸 모르는 사람의 문제지만, 현실적으로는 이해가 되는 부분도 있다.

어떤 응답 로직을 구현하기 위해 적합성 여부를 여러번 생각해야하는 것은 어쨌든 일종의 비용이라고 생각한다.

https://1ambda.github.io/javascripts/rest-api-put-vs-post/
- 여기서 response code decision tree를 볼 수 있을 것이다

물론 이것은 REST의 문제가 아닌 구현상의 어려움일 뿐이다.

이 글을 비판하는 진영에서는 ‘아니, 그게 왜 어렵다는 거야?’같은 반응을 보이기도 한다
사족이지만, npm 개발자인 Isaac Z. Schlueter는 세미콜론을 최대한 안 쓰는데, 이런 방식은 버그를 양산할 수 있고 혼란스러울 수 있다고 비판하는 사람들에게 ‘네가 JavaScript 문법을 몰라서 그렇다’고 일침하기도 했다

요청 메소드와 응답 코드가 모든 상황을 담아낼 수 없다는 의견도 있는데, 이 글에 동조하는 사람들은 거대한 엔터프라이즈 환경(ERP, 병원 시스템 등)에서 다양하고 복합적인 리소스를 다루는 상황에 대해 언급한다.

논쟁을 지켜보며 생각이 드는 것은 - 추측이지만,

메소드가 충분치 않다는 감정은 특히 RPC를 실행하는 경우,
그러니까 내부적으로 복잡한 로직이 섞여있을 때 발생하는 것 같다.

예를 들어 리퀘스트를 날려서 설거지와 빨래와 아이 목욕을 시킨다면, 여기서 리소스란 무엇일까? 이 때는 어떤 메소드를 써야하는가?

이 지점부터 한차례 혼란이 오는 것 같은데, 그 리퀘스트를 보내는 대상 리소스가 우리가 흔히 인식하는 리소스, 그러니까 CSS나 이미지같은 소위 정적 리소스 개념을 벗어나는 지점부터 어려워지는 것 같다.

HTTP에서 리소스란 뭐든 지 될 수 있다.

또한 REST를 CRUD로 치환하는 순간 이견은 좁혀지지 않는다.

조회/등록/수정/삭제를 GET/POST/PUT/DELETE로 처리하는 게 REST라고 생각하면 더 이상의 이성적인 논쟁은 불가능해진다.

HTTP 메소드가 부족하다고 생각이 드는 건 모든 RPC 요청의 성격을 CRUD에 매핑하려는 시도에 원인이 있다고 본다.

어떤 기분인 지는 알 것 같다.

REST API는 GET/POST/PUT/DELETE를 쓰는 것 -> 곧 조회/등록/수정/삭제를 의미 -> RPC 업무는 조회/등록/수정/삭제 네 가지로 단순하게 떨어지지 않아!

각 HTTP 메소드가 정확히 어떤 의미인지는 각자 (제발 신뢰할 만한 출처에서) 찾아보기로 하고,

REST 논문에는 애초에 CRUD나 어떤 HTTP 메소드를 써야 한다는 언급이 없었다.

‘REST API는 GET/POST/PUT/DELETE를 쓰는 것이다’라는 공식은 웹 프레임웍의 잘못된 가이드에도 원인이 있기도 하다.

Ruby on Rails의 예를 보자.

PUT을 썼더니 방화벽에서 막혔던 사례를 통해 이때 발생할 수 있는 문제를 다루고 레일스의 잘못된 가이드에 대해 언급한다
마지막 결론쯤에 Rails는 Rails일 뿐이라는 대목이 나온다
Best practice를 쫓아가면 좋긴하지만, 이해용이성을 조금 포기해야 하기도 한다

PHP의 Laravel은

5.2 버전까지 RESTful Resource Controllers라는 용어를 사용했으나,
5.3 버전부터는 typical "CRUD" routes를 제공한다는 설명과 함께 Resource Controllers라고 변경했다. 하지만 여전히 PUT은 UPDATE에 대응이 된다.

307 Temporary 같은 애들은 브라우저마다 상이하게 처리되기도 한다. 제대로 지원하는 건 200과 500뿐이다.

좀 오버하는 감은 있긴 하다.

하지만 REST에서는 Uniform Interface가 중요한데도 경험적으로 (적어도 HTTP 쪽에서는) 인프라가 충분치 않다는 인식이 있는 것 같다.

위에 Ruby on Rails의 예에서 언급한 것처럼 보안을 이유로(?) PUT을 지원하지 않는 방화벽이랄지,

HTTP 응답 코드를 각기 다르게 해석하는 클라이언트 등 현실적인 제약은 다반사인 것 같다.

구현을 하는 입장에선 아무래도 이런 부분에선 부담이 되는 게 사실이다. (IE 대응을 위해 버려진 수많은 나날을 생각해보자)

HTTP의 문법은 풍부하지 못해서 모든 어플리케이션의 요청과 응답을 표현할 수 없다

이것도 사실 각자의 상황에 맞는 Best Practice의 부재 탓이라고 본다.

HTTP가 끝없는 업계의 요구사항에 매번 응답코드를 추가해줄 수는 없다.

답답하겠지만 결국 개발자는 결정을 해야한다. 현실 세계의 문제는 원래 그렇다.

RESTful API는 디버깅 하기 힘들다

이에 대한 반론 중에는 개발자도구나 HTTP client 툴을 사용하면 된다고들 하지만,

이 블로그 글쓴이의 의도는 요청/응답 시 신경써야 하는 부분이 많다는 것이다.

난 맞는 지적이라고 생각한다.

SOAP이나 GraphQL처럼 응답 메시지 본문에서 모든 상황을 지켜보고 싶은 마음을 나도 십분 이해한다.

하지만 REST는 쉽게 개발하려고 만든 아키텍처 스타일이 아니다.

웹의 인프라를 충분히 활용해서 효율적으로 동작하고, 독립적으로 진화하고, 확장할 수 있게 설계하기하기 위함이다.

디버깅을 편하게 하기 위해 설계 원칙을 바꾸는 순간 본래의 목적에서 멀어진다.

HTTP에 너무 종속되어 있다

웹에서의 주요 프로토콜이 HTTP이긴 하고, 그 때문에 REST를 구현했다는 사람들이 HTTP를 많이 쓸 뿐이지 REST는 HTTP에 한정되지 않는다.

5.3.2 Connector View 참고

아무리 이론적으로는 맞는 말일 지라도, 현실적으로는 대부분 HTTP 위에서 REST를 구현할 수 밖에 없잖아

맞다. 웹개발자 입장에선 대부분의 API 설계를 HTTP 위에서 하게 된다.

하지만 그것이 REST가 HTTP에 종속됐다는 의미는 아니다.

HTTP를 재발명 하자는 게 아니다. 단지 어플리케이션 레벨의 메시지를 HTTP 안에 억지로 끼워넣지 말고 JSON payload에 담자는 말이다.

그래도 된다고 생각한다. 다만 그렇게하면 REST라고 부르지 말자는 것이다. REST라고 부를 수 없다고 나쁜 설계는 아니다.

글쓴이가 제시하는 JSON-Pure API는 “json-ld/hydra”와 같은 hypermedia를 사용하는 REST(중의적인 의미) 사람들을 따라하고 있을 뿐이라는 의견도 있다. (지원하는 클라이언트가 얼마 없지만…)

hypermedia를 구현하기 위한 수많은 API 표준이 존재하는데, 후속 블로그에서 더 다뤄보겠다.

JavaScript를 비활성하면 REST를 쓸 수가 없다. HTML은 GET/POST밖에 지원하지 않는다.

계속되는 HTML의 PUT/DELETE 지원 논쟁.

XHR을 쓰면 된다는 부류와 XHR을 못쓰는 환경이 있는데 어떡하냐는 부류가 자주 부딪힌다.

미안하지만 REST는 Architectural Styles일 뿐 당신들이 request 하나하나를 어떻게 구현하는지 관심이 없다.

내 개인적인 생각으로는 어느 시스템이든 각각의 제약 사항은 존재하기 마련이다.

부족하면 부족한대로 해결해내는 것이 개발자가 할 일이라고 본다.

그러다보면 REST의 제약사항을 어길 수밖에 없는 상황도 분명 올 수 있겠지.

다시 말하지만, 그럼 REST라고 안 부르면 된다!

가장 적당한 디자인을 설계하자.

가서 SOAP으로 입 좀 행구고 오지 그래

네가 하려는 건 SOAP과 다를 바 없다는 중의적 의미.

댓글에서 SOAP과의 비교를 하는 사람이 참 많다. 여기 REST와 비교한 글도 참고하자.

(이 블로그는 국내에서 보기 드물게 REST에 대해 정확한 표현을 하고 있음에도 이 글에서는 제대로 REST를 설명하고 있지 않는데, 그 이유는 ROA에 관한 그 분의 다른 글에서 볼 수 있다. 여기서 REST는 아키텍처 스타일, RESTful Web Service는 아키텍처로 구분하고 있는데, 이게 얼마나 신방성 있는지는 좀 더 찾아봐야겠다. ROA는 나중에 다시 다뤄보겠다.)

‘소위 REST’가 SOAP을 대체해 나간 것처럼 기술이 오래 살아남기 위해선 사람들이 얼마나 쉽게 받아들일 수 있는가도 무시할 수 없는 것 같다.

결국 누군가 나서서 논쟁을 정리한다

(좋은 내용인데 이렇게 밖에 해석할 수 밖에 없어서 미안하다)

REST는 API가 아니야. API를 디자인 하기 위한 패턴이야. 그것은 매우 엄격하게 또는보다 실용적인 방식으로 고수 될 수 있으며 현실 세계에서 구현하기 위한 모범 사례가 무엇인지에 대해 의견 차이가 있지.
XMLHttpRequest는 모든 CRUD문법을 지원하고 있어. 10년 정도를 넘지 않은 모든 메이저 브라우저는 REST를 완벽하게 지원해.
REST API는 도메인에 종속된 메시지 교환을 충실히 지원하는게 목적이 아니야. HTTP 레이어가 트랜잭션의 상태에 대한 정보를 갖고 있지. 즉, 일반적인 HTTP client와 프로토콜을 구현할 의무가 있는 서버에게 유용한 방식이야. 이 컴포넌트들이 도메인 특정의 어플리케이션이 도메인에 종속된 로직을 처리하도록 메시지 페이로드를 전달하고 있지. 이건 대부분의 메시지 교환 방식에서 사용하고 있어. 프로토콜에서 하나의 역할을 하는 시스템은 자신이 필요한 부분만 읽고 서브 시스템에게 넘겨주지. TCP/IP 위에서의 HTTP 응답을 예로 들면 IP packet과 TCP 헤더는 HTTP client가 읽기도 전에 TCP client에서 읽히고 처리되지. 단순히 다음 프레임으로 넘어가서 메시지를 해석할 수 있는 어플리케이션 코드에게 메시지를 전달하면 되는데, 왜 굳이 HTTP 프로토콜을 확장해야 하는거지? 모든 REST 원칙은 URL이나 HTTP 동사와 같은 일반적인 개념을 제공하는 HTTP 프로토콜을 이용하고, 이를 페이로드 안에서 재발명하지 않을 것을 권고하고 있어. 그렇게 함으로써 페이로드의 내용을 더 가볍고 간단하게 만들 수 있고, 대부분의 HTTP client가 공짜로 제공해주는 캐싱 같은 이점도 누릴 수 있지.
네가 언급한 7가지 영역은 사실 모두 요청과 응답이라는 2개의 조각에 나뉘어 있어. 커스텀 JSON에 모두 묻어버릴 때와 같이 말이지. 다른 점이 있다면, 대부분의 개발자는 이미 이 형식에 익숙해서 HTTP 요청과 응답 안의 정확히 어디를 봐야할 지 안다는 사실이지. HTTP 인터렉션을 디버깅을 위한 (네 브라우저에도 있는) 훌륭한 툴을 모두 언급하지는 않을게.
내가 이미 지적했지만, REST는 API설계를 위한 패턴이지 HTTP로 제한된 건 아니야. RESTful한 디자인 관점은 네 API를 대부분의 전송 프로토콜 안에서 깨끗하고 일관되고 성능도 좋고 캐시하기도 좋게 도와주지. HTTP에서 적용하기 쉬운 이유는 REST의 많은 원칙들이 HTTP로부터 영향을 받았기 때문이야.
넌 프로토콜과 컨텐츠에 대해 혼란스러워하고 있어. 네가 말하고 있는 건, HTTP 프로토콜의 3가지 information 조각이야. 리소스 식별자, 명령어 동사, 응답 코드. 응답코드가 메시지 컨텐츠로 절대로 볼 수 없다고는 말할 순 없지만, 트랙잭션의 상태를 나타내는 표준 코드는 완전히 프로토콜의 일부야. 나머지 것들도 메시지 교환에서의 보편적인 개념이고 프로토콜 레이어 상에서 이를 명시하는 것은 아무런 해가 되지 않아.

결론

많은 사람들은 REST가 좋은 설계 패턴이라고 생각하면서 REST를 제대로 이해 못한 채 API/서비스를 만들고 여기에 RESTful이라는 표현을 쓰고 있다.
그건 REST가 아니라고 말을 해줘도, 그럼 어떻게 구현하냐고 따지고 든다.

마치 REST라는 용어를 반드시 써야만 하는 사람들처럼.

2008년 논문의 저자 Roy도 사람들이 REST에 대해 오해하는 것에 대해 한탄하며 글을 썼는데, 이는 다음 포스트에서 다룰 예정이다.

이 논쟁에서 등장한 근거와 여러 링크가 궁금하다면 제일 하단 추천 링크도 확인해 볼 것!

댓글 정리

양이 너무 많아서 정말 대충 막 그냥 해석해서 써갈겼지만, 써 놓고 보니 또 아깝고 해서 쓸데 없지만 붙여 넣어본다.

각 댓글 앞에는 이 글에 대한 찬반 표시를 했다

이 글에 찬성하는 편 👍
이 글에 반대하는 편 👎
쓸데없는 소리 💩

👎 너 정말 REST를 제대로 이해하는 거 맞어?
👎 그 문법이 좀 혼란스러운 건 맞어. 그런데 그건 HTTP의 문제 아니냐?
👎 REST는 HTTP에 종속된 게 아니야

💩 난 왜 이걸 (머릿속에서) 화난 목소리로 읽고 있는거야
👍 무슨 소리야. HTTP의 문법이 사용되고 있는데. 그리고 현실에선 99%는 HTTP위에서 쓴다고
- 👎 로이 필딩의 논문 Section 5.2.1.2는 너랑 생각이 좀 다른 것 같은데? REST는 아무 representation이나 사용할 수 있어. 바이너리 프로토콜이라도 말이지.
  - 👍 원래 논문이 어쨌든 현실에선 아무 의미가 없어. 단지 몇 가지 아이디어와 이름만 가져왔을 뿐이라고.
    - 👎 아닌데? 최초 거기서 설명된 것이 바로 핵심이야. HTTP 동사와 상태 코드에 어플리케이션 관점의 의미를 부여하는 게 사실상의 REST의 의미가 되고 있지만, 내 생각엔 그건 REST의 핵심이 아니야. 하지만 오늘날의 이른바 REST를 원래 묘사된 것보다 더 관련있고 유용하고 정확하게 만들어주는 그런 구현이 없긴하지.
    - 👎 어떤 면에서는 반대로 생각해. 어플리케이션 도메인의 의미를 HTTP 도메인으로 확장하려고 하면 좋은/우수 사례는 존재하지 않아. 단지 다양한 의견, 느슨한 명세와 설명의 묶음이 될 뿐이지. 사실 그 중 어느것도 확실하게 실용적인 주장이라고 정당화하긴 어려워. 요즘 널리 퍼진 소위 RESTful 베스트 프랙티스는 대부분은 개발자들 기분 좋으라고 있는거지, 원래의 의미를 기초로 하거나 필요로 하지 않는 것들이야.

👎 인터넷 이야기를 해보자고. 그 거대하게 연결된 웹 자체가 이미 REST가 잘 동작하는 훌륭한 예라고. 20만개의 사이트가 20년 후에도 잘 돌아갈 거야.

👍 뭐가 잘 동작한다는 거야? 평이한 링크들은 관심도 없거니와 여기서 다루는 문제가 아니야. 여기선 REST가 어떻게 사용되고 있는가에 대해서 이야기 한다고. 특히 IPC같은 것들.
👍 20만개의 사이트가 잘 돌아가는 건 그동안 문서의 저장소로서 존재했기 때문이야.

👎 오해를 한 것 같은데, REST는 전송 프로토콜과 언어에 대해서는 언급하고 있지 않아. 위키디피아를 봐 “RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol “
👍 당신이 아무리 철학적으로 올바른 말을 해도, HTTP위에서 REST를 구현하려는 시도는 어쩔 수 없는 현실이야. 쉽고 객관적으로 써보려고 노력했는데 잘 안된 것 같군. 곧 JSON-pure API에 관한 추가 포스팅을 올리도록 하지

👎 신경질적으로 반응한 건 미안한데, 글 제목이 좀 자극적이긴 하잖아. 당신의 그 json-pure api는 어떻게 전송하는지 말해줄래?
- 👍 우선 다음 포스트(링크)를 확인하면 많은 부분 답이 될 거야
- 👍 REST에 관한 나의 묵상..이렇게 제목을 지어놓으면 누가 보기나 하겠어?
- 👍 난 HTTP를 재발명하자고 제안하는 게 아냐. http는 훌륭한 매커니즘이고, json은 GET이나 POST를 사용해 표준 application/json contents-type으로 HTTP위에서 전송이 되지. 난 대부분의 어플리케이션 레벨의 메시지를 http안에 억지로 끼워넣지 말고 json안에 넣자는 거야. 그게 훨씬 api를 간편하고 신뢰할 수 있게 만들어 주니까.
- 👍 어쨌든 이미 많은 사람들이 이 문제를 지적했다고 확신해. 이게 뭐 대단한 것도 아니고. 난 웹개발자의 관점에서 전형적인 RESTful API 구현체가 왜 종종 안 좋은 방법인가에 대해 간략하게 정리하고 싶었을 뿐이야.
- 👍 추가: 내가 일반적인 http를 예로 들었지만, 이 방법은 쉽게 웹소켓이나 다른 전송 방식에서 구현할 수 있어. json에 요청과 응답에 필요한 거의 모든 것을 넣어놨기 때문이지.
- 👎 사실 너는 “json-ld/hydra”와 같은 hypermedia를 사용하는 REST(중의적인 의미) 사람들을 따라하고 있을 뿐이야. 그 사람들이 더 잘하고, 표준도 만들고 있고, http를 해치지도 않지. 이미 존재하는 것을 이용하는 게 더 좋긴 하지만, 이 방식의 가장 큰 문제는 hypermedia의 개념이 아직 널리 퍼지지 않아서 지원하는 클라이언트가 엉망이라는 점이야.
- 👍 뭐하러 직렬화한 것을 전송하는데 contents-type까지 붙여야 하지?…(역주) 이렇게 시작하는 답글이 있으나 문장을 끊어쓰지 않아서 뭔 소린 지 잘 모르겠음. 어쨌든 다양한 클라이언트를 대응하고 클라이언트가 기대하는 대로 응답하기에는 좋은 생각인 것 같다는 말인 것 같음.
👍 정말 재밌게 읽었어. api를 설계할 때 나눠야할 깊은 논의에 있어 좋은 출발점이 될 것 같아.
- 👍 고마워 넌 다음 글도 좋아할 것 같아
💩 에헴 graphql 에헴 (역주 graphql이란 게 있는데…란 )

👎 디버깅하기 어렵고 DELETE/PUT이 지원하지 않는다고? 지금 몇년도에 살고 있는거야?

👍 2016에 html form에서 DELETE/PUT이 지원하나보지? 지원 안하면 javascript를 disable시킨 환경에서 어떻게 rest를 사용할건데? - 이건 인터뷰 질문으로 쓰기 좋겠구만
- 👎 누가 2016년에 request 보내는데 form을 쓰냐? 누가 2016년에 js를 끄고 브라우저를 쓰고 누가 js가 제공하는 기능을 모두 기대하겠냐고. js를 켜는 것은 2016년에는 필수라고.
  - 👍 많은 큰 기업에서 보안을 이유로 xhr을 끄고 form을 쓰도록 하고 있어. 이름을 댈 수는 없지만 많은 기업이 여전히 IE7을 쓰고 있고 심지어 일부는 xp에 ie6을 쓰고 있지.
    - 👍 그리고 ajax는 일반적인 브라우저의 네비게이션 히스토리를 따르고 있지 않아. 그렇다면 history api를 써야겠지? 그러다 이런 생각이 들거야. 왜 여전히 form이 html의 가장 주요한 스펙으로 남아있을까.
    - 👍 나도 요즘엔 form이 덜 쓰인다고 생각해. 내가 하고싶은 말은, 당신이 어떤 길을 걸어갔던지 모든 문제는 항상 그렇게 간단하지만은 않다는 거야.
  - 💩 별 바보같은 댓글 다 보겠네 ㅋ 그럼 html5나 css도 호환성 문제가 있으니 갖다 버리라고 그래.
  - 👍 많은 큰 기업들이 보안을 이유로 PUT과 PATCH를 막고 있어. 최근 일했던 곳에서 이 둘을 허가받기 위해 엄청 설명을 해야했어. 큰 기업 환경에선 완전한 RESTful은 아직 쉽지 않지.
👎 내가 오해를 하고 있나? 확인해보니 HTML에서 둘 다 잘 지원하는데?
- 👍 GET, POST, PUT and DELETE 이런 거는 다 HTTP 표준인데, HTML에서 지원하는 건 GET/POST 밖에 없어. 최신 브라우저는 지원할지도 모르겠지만, 대부분의 개발환경은 2010~2013년 시대에 머물러 있어. http://laraveldaily.com/theres-no-putpatchdelete-method-or-how-to-build-a-laravel-form-manually/ 이런 걸 봐.
  - 💩 1970년대에 살고 있으면 비주얼 베이직이나 어셈블러나 하시지. 지금 2017년이야 정신차려.

💩 가서 비누(역주 : 그거 SOAP 아니냐는 중의적 의미)로 입 좀 행구고 오지 그래

👍 웃긴 건 둘째치고, 이건 SOAP이랑 다른 거야. SOAP의 문제는 복잡성과 망할 스펙이지. 내가 해봐서 알아. 이건 너네의 HTTP 기반의 RESTful보다 훨씬 쉽다고.

👎 마이클! 로이와 그의 논문에 대한 항목은 좀 축소하거나 삭제할 필요가 있어. 당신이 설명하는 것은 HTTP 위에서의 CRUD이지 로이가 설명했던 것과는 달라. 사실 그게 REST라고 불리고는 있지만, 로이의 논문과 관련있는 것은 단지 사람들이 완전히 다른 것을 가져오기 위해 납치한, 그가 사용한 REST란 이름 뿐이라고. REST에 대한 현대적 관행의 결점을 그의 탓으로 돌리는 건 공정하지 않아.

👍 나도 당신의 의견에 동의하고, 당신이 쓴 그 내용을 서론에 추가해도 좋을 것 같아. 괜찮아? 내가 RESTful web services에 대해 논의했던 모든 웹개발자는 위에 쓴 그대로 REST를 설명하고 있었어. 맞아, 메소드들과 응답코드를 사용하긴 해도 기본적으로는 HTTP위에서의 CRUD일 뿐이지. 다음주에 더 설명해볼게.
- 👎 고마워. hypermedia api를 한번 살펴봐 “RESTful Web API 웹 API를 위한 모범 전략 가이드”란 책이나 https://groups.google.com/forum/#!forum/hypermedia-web 을 아직 모른다면. 거기선 사람들이 CRUD를 REST와 헷갈리지 않거든. 너도 아마 좋아할거야.

👎 난 네가 JSON을 사용하는 SOAP을 쓰자고 하는 것 같은데. 세세한 제약이 있는 RPC스타일 API가 어려운 건 다 이유가 있어. 많은 이가 지적했지만, 보통 오해하는 것처럼 REST가 CRUD는 아니야. HTTP 동사를 CRUD로 단순화하면 representation의 개념을 놓치게 돼. 이는 그 패턴이 잘 돌아가게끔 도메인 엔티티를 추상화하지. 나아가 각자가 정의한 의미들을 JSON payload에 담아보내는 것이 HTTP동사/응답 패턴보다 쉽다고 하는게 이해가 안돼. 적어도 HTTP동사/응답에 관해선 표준적인 사용법이 있잖아.

👎 하나 더 이야기하자면, REST의 HATEOAS관점은 매우 중요해. 로이도 그렇게 이야기 했고. 그걸 지키지 않은 건 REST라고 할 수 없지. 이건 SOAP의 정적인 발견가능성을 넘어서, 제대로만 만든다면 API를 실시간으로 인터렉티브하게 만들어줄 수 있지.

👎 이런 끔찍한 글을 쓰기 전에 REST나 공부해. 틀린 점을 말해줄게. #1. 코드의 의미는 API개발자들이 잘 이해하고 있어. #2. 동사들을 지원하기 위해 API 설계자들은 그걸 다 구현해야 하지(모든 웹 서비스가 다 그런 거잖아. 이상한 소릴 하는구만). 이건 API설계에 대한 이야기야. HTML이 몇몇 동사를 지원하지 않겠지만, API에 HTML을 사용해선 안돼. 그래서 JSON이나 XML을 써야하지. #3. 추가적인 동사는 필요없어. 리소스 기반 설계에 대해 공부 좀 해봐. 내가 아래에 몇가지 알려줄게. REST는 특히 캐싱에 대해 고려하거나 이로써 대역폭에 관해 효율적으로 동작해. #4. REST는 디버깅이 존* 쉬워. 브라우저나 Firebug, postman 등… 사실 REST가 가진 장점이라고 할 수 있지. 다른 웹서비스는 훨씬 더 어렵다고. #5. REST가 HTTP에 강력하게 묶일 필요는 없어. 다른 프로토콜을 섞어 쓸 수도 있고, 그게 안티 패턴도 아냐. 더 이상 나쁜 소리하기 싫으니까 조만간 내가 추천하는 걸 좀 찾아보길 바라. API-craft google group, Books: REST in practice, RESTful Web APIs, RESTful Webservices

👍 트위터나 그런 10~20개 정도의 리소스를 매핑할 수 있는 아주 제한된 기능을 가진 사이트에서는 아주 훌륭한 이야기들이야. 그런데 이런 사이트들은 실제 비지니스 시스템에 비해 아주 원시적인 기능들만 제공할 뿐이야. 내가 10년이상 REST를 경험해봤는데, REST를 제대로 할 수 있는 시스템은 본적이 없어. 다른 사람들도 내가 하고있는 의료 분야처럼 복잡한 어플리케이션을 다루고 있어. 200개의 테이블이 있고, 150개의 트랜잭션을 위한 테이블이야 말할 것도 없고…REST를 사랑하시는 여러분이 내가 하고 있는 시스템에서 ‘적절한 REST’ 인터페이스를 정의해나가는 게 얼마나 걸릴지 궁금하군. 당연히 JSON RPC API가 유지보수하기에 훨씬 쉽고, 네가 REST로부터 멀어질 수록 더 단순하고 유지보수 비용이 줄게 되지. REST는 작은 서비스에서 쓰기 좋은 거라고.
- 👍 브라우저에서 돌아가게 만든 ERP중에 REST로 구현할 놈은 하나도 없을 거라 생각해. 불행히도 많은 웹 개발자들은 ERP가 뭔지도 잘 몰라. 맨날 리소스, 확장성같은 거만 생가하지. 고객들은 빠른 응답과 브라우저에서 데스크탑 프로그램의 룩앤필을 갖는 것 등을 원하는데 말야. RESTful은 이걸 절대 이룰 수 없어. 요구사항이 적을 때나 가능한 일이라고.
  - 👍 ERP에 대한 설명이 웃기네. 완전 맞는 말이야. 이해관계자들은 REST가 아닌 비지니스와 회계를 신경쓰지. 빠른 개발과 응답을 원하고. 아무도 백엔드가 어떻게 생겼는지 신경 안 써. 어마어마한 요구사항에는 SOAP이 더 낫지. 난 SOAP이 싫지만 의료업계의 회계같은 곳에선 더 간단하다고 볼 수 있지.

👍 내가 본 대부분의 json api는 심지어 REST가 아냐. twitter의 ‘REST’ api를 봐. 물론 몇 개는 REST라고 할 수 있지만, 저건 RPC에 가깝지.
👎 결국 넌 REST의 목적을 이해하지 못하기 때문에 REST가 나쁘다고 말하는 거구나.

👍 아니, 난 REST를 시도때도 없이 사용하는 게 안 좋다는 거야. (곧 릴리즈될) Facebook Relay and Netflix Falcor도 - 전통적인 RESTful API를 벗어나는 것에 대한 - 같은 주제를 다루고 있지.
👎 xhr 클라이언트는 request를 위한 모든 환경을 제공하고 있어.
- 👍 맞아. 그러나 그건 XHR뿐이지, 다른 영역에선 여전히 GET/POST만 제공하거든. 그리고 응답코드에 대해 지원하는 수준도 천차만별이야. 오래된 브라우저는 더 심하고. 게다가 네 client가 patch 메소드를 보낼 수 있다고 쳐도 서버가 그걸 구현했다는 의미는 아냐.
👎 네가 이런 혼동에서 빠져나오기를 바란다
- 👍 첫째, 난 혼란스럽지 않아. 둘째, 인신공격이 널 더 똑똑하게 만들어주지 않아.
  - 👎 인신공격이라고? 넌 혼동하는 게 맞아. 그건 팩트라고. 다른 코멘트도 모두 네 논리에 대한 결함을 이기 하고 있고. 넌 네가 이해하지 못하거나 구현할 수 없는 것에 대해 배척하는 것 뿐야.
  - 💩 (역주) 이후 개싸움이라 생략…

💩 2 Years later … GraphQL is rising. And GraphQL only use 200 and 500.
👍 API 제공자가 아닌 소비자로서의 나의 문제는, 어떻게 파라미터를 전달할 지, 서비스를 어떻게 노출할 지, 리턴 데이터가 어떻게 되어야 할지 일관된 방법이 없다는 것이다

👍 기본적으로 HTML을 통한 REST는 form에서 PUT, POST 등을 지원하지 않기 때문에 완전하지 않다. 왜 RESTful하기 위해 굳이 form이 아닌 xhr을 써야하나? 삭제는 어떻게 해야하는거야? HTTP+HTML만으로는 실무에서 제대로 구현하는 게 불가능하지.

👎 내 생각에 REST의 유일한 문제는 REST 자체가 아니라 그걸 쓰는 사람들의 문제야. 왜냐면 REST는 종종 HTTP와 혼동하거나 HTTP없이는 구현할 수 없다고 생각하거든. 너도 똑같은 실수를 하는 것 같다고 생각하는 이유는, 넌 HTTP의 상태코드나 동사에 대해 불만이 있다고 말을 하지만 그건 REST랑 상관이 없는 얘기거든. 그건 HTTP에 정의된 거라고. 물론 네가 REST를 HTTP를 통해 구현할 수 있기도 하고, REST를 구현한다는 서비스들이 99%는 http를 쓰고 그 속성을 상속받게 되긴 하지.

👎 네가 지적한 건 뭐 하나 제대로 된 게 없어

1 . REST는 API가 아니야. API를 디자인 하기 위한 패턴이야. 그것은 매우 엄격하게 또는보다 실용적인 방식으로 고수 될 수 있으며 현실 세계에서 구현하기 위한 모범 사례가 무엇인지에 대해 의견 차이가 있지.
2 . XMLHttpRequest는 모든 CRUD문법을 지원하고 있어. 10년 정도를 넘지 않은 모든 메이저 브라우저는 REST를 완벽하게 지원해.
3 . REST API는 도메인에 종속된 메시지 교환을 충실히 지원하는게 목적이 아니야. HTTP 레이어가 트랜잭션의 상태에 대한 정보를 갖고 있지. 즉, 일반적인 HTTP client와 프로토콜을 구현할 의무가 있는 서버에게 유용한 방식이야. 이 컴포넌트들이 도메인 특정의 어플리케이션이 도메인에 종속된 로직을 처리하도록 메시지 페이로드를 전달하고 있지. 이건 대부분의 메시지 교환 방식에서 사용하고 있어. 프로토콜에서 하나의 역할을 하는 시스템은 자신이 필요한 부분만 읽고 서브 시스템에게 넘겨주지. TCP/IP 위에서의 HTTP 응답을 예로 들면 IP packet과 TCP 헤더는 HTTP client가 읽기도 전에 TCP client에서 읽히고 처리되지. 단순히 다음 프레임으로 넘어가서 메시지를 해석할 수 있는 어플리케이션 코드에게 메시지를 전달하면 되는데, 왜 굳이 HTTP 프로토콜을 확장해야 하는거지? 모든 REST 원칙은 URL이나 HTTP 동사와 같은 일반적인 개념을 제공하는 HTTP 프로토콜을 이용하고, 이를 페이로드 안에서 재발명하지 않을 것을 권고하고 있어. 그렇게 함으로써 페이로드의 내용을 더 가볍고 간단하게 만들 수 있고, 대부분의 HTTP client가 공짜로 제공해주는 캐싱 같은 이점도 누릴 수 있지.
네가 언급한 7가지 영역은 사실 모두 요청과 응답이라는 2개의 조각에 나뉘어 있어. 커스텀 JSON에 모두 묻어버릴 때와 같이 말이지. 다른 점이 있다면, 대부분의 개발자는 이미 이 형식에 익숙해서 HTTP 요청과 응답 안의 정확히 어디를 봐야할 지 안다는 사실이지. HTTP 인터렉션을 디버깅을 위한 (네 브라우저에도 있는) 훌륭한 툴을 모두 언급하지는 않을게.
내가 이미 지적했지만, REST는 API설계를 위한 패턴이지 HTTP로 제한된 건 아니야. RESTful한 디자인 관점은 네 API를 대부분의 전송 프로토콜 안에서 깨끗하고 일관되고 성능도 좋고 캐시하기도 좋게 도와주지. HTTP에서 적용하기 쉬운 이유는 REST의 많은 원칙들이 HTTP로부터 영향을 받았기 때문이야.
넌 프로토콜과 컨텐츠에 대해 혼란스러워하고 있어. 네가 말하고 있는 건, HTTP 프로토콜의 3가지 information 조각이야. 리소스 식별자, 명령어 동사, 응답 코드. 응답코드가 메시지 컨텐츠로 절대로 볼 수 없다고는 말할 순 없지만, 트랙잭션의 상태를 나타내는 표준 코드는 완전히 프로토콜의 일부야. 나머지 것들도 메시지 교환에서의 보편적인 개념이고 프로토콜 레이어 상에서 이를 명시하는 것은 아무런 해가 되지 않아.
👍 여기에 블로그 글쓴이가 논점에 벗어난 댓글을 담
- 👎 여기에 다른 이가 항의함
  - 네가 말하는 건 모두 DSL interface를 만들기 위해 REST의 원칙들을 왜곡하려는 것 같은 일이야. 난 개인 감정으로 네 주장에 대해 지적하는 게 아냐. 넌 너무 방어적이라고. 네가 지적한 기술적 문제는 REST에 대한 납득할 만한 비평이 아냐. 모두가 지적하는 부분에 대해 그저 동의하는 척 끝내버리고 있어. 넌 기술적인 원칙들과 네 안 좋은 경험들을 분리하는 데 문제가 있는 것 같아. REST가 의도하지 않은 방향으로 구현된 걸로 REST를 까지말고, 구체적으로 네가 생각하는 이상적인 기술적인 세부사항을 그려보지 그래? 네 블로그 글은 REST의 결함에 대한 이해는 되지 않고, 왜 그것이 종종 잘못 구현됨으로써 만능 해결책이 되지 않는지에 대한 내용 뿐이야.