REST는 이론적이고 순수한 제약이 있는 이상적인 "가이드라인"이고 RESTful API는 REST에서 영감을 받아 REST의 특징을 적용한 "실용적인 웹 API"이다.

실용적이라는 말은 해석하기 나름이지만, 웹 API는 사용하기 쉬워야 한다는 데에는 다들 동의하는 편이다. 외부 개발자가 보았을 때 이해하기 쉬워야 하고, 일관되어야 하고, 예측 가능하고, REST의 많은 부분을 따라야 한다. REST의 어떤 디자인 면을 구현하면 이런 종류의 사용 편의성이 생긴다. 사람들이 종종 생각하는 바와는 달리, REST 제약은 원래 단기 생산성이나 개발자의 사용 편의성에 대해서는 별 관심이 없이 만들어졌다.

REST는 수십 년에 걸치도록 만들어진 소프트웨어 디자인이다. 모든 세부사항은 소프트웨어의 수명을 연장하고 독립적으로 발전할 수 있게 하려는 것이다. 제약의 상당수가 단기적인 효율 면에서는 부정적인 효과를 가져온다. -- 로이 필딩

그렇다면 실용적으로는 REST의 어느 부분을 적용하는 것이 가장 쉬울까? 명사를 이용해서 HTTP 동사가 동작을 취하는 자원(URI)을 일관되게 식별하는 것이 REST의 기본이다. REST에는 성능에 대한 특별한 요구사항은 없지만, 실용적으로는 캐시 자원을 참조하는 기능이 있으면 시스템의 수행과 확장을 돕는다. REST는 추상적인 모델로 여겨지기 때문에 시간에 따라 시스템이 변할 것이라는 사실을 직접적으로 고려하지 않지만, RESTful API는 실용적으로는 API를 변경할 때마다 가능한 이전 시스템과 호환성을 유지하는 방식으로 API 버전을 부여하면 상당한 유연성이 생긴다. 그리고 REST는 클라이언트와 서버를 확실히 분리한다는 설계 자체가 엄청난 이점이 있어 애플리케이션의 개발을 돕는 경향이 있기 때문에 웹 개발에서 영향력이 매우 커졌다. REST의 이런 면을 활용하면 결과적으로 쉽게 이해하고 확장할 수 있는, 공학적으로 우수한 애플리케이션을 만들 수 있다.

RESTful API의 일부 특징은 REST와 상충한다. 가장 주목할 점은, 데이터 전송 방법으로 JSON을 채택한 것이다. JSON은 하이퍼텍스트 링크를 페이로드 할 수 없으므로(최소한 널리 수용된 링크 메커니즘이 없다.) REST의 HATEOAS(Hypermedia As The Engine Of Application State)를 실현할 수 없다. JSON을 사용하면 응답 유형 자체에 정의된 연결을 할 수 없다. 연결할 수 없는 매체를 사용하면, API는 자기 설명적이지 않게 되고 따라서 문서가 필요한 API가 된다. HATEOAS가 이론적으로는 설득력이 있어도, 지속적으로 구현하기에는 어려움이 있는 것이 사실이다. JSON이 웹 API를 위한 사실상 표준 데이터 전송 포맷으로 널리 채택되었기에 더욱 어렵다.

REST 제약 중 하나가 일관된 인터페이스(Uniform Interface)라는 점을 상기해보자. 일관된 인터페이스는 거의 완전히 자기 설명적이다. 이상적으로, 이런 인터페이스로 된 시스템은 시스템의 진입점 이상의 문서가 필요하지 않다. RESTful API는 모든 자원에 대한 링크를 제공하고, 그 외의 설명을 추가하지 않는다. 현실적으로는, 웹 API의 문서가 잘되어 있으면 RESTful API가 훨씬 더 사용하기 쉽다.