메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙

리얼타임 eBook

번역서

판매중

  • 저자 : 마크 마세
  • 번역 : 권원상 , 김관래
  • 출간 : 2012-10-18
  • 페이지 : 141 쪽
  • ISBN : 9788979149456
TAG :
초급 초중급 중급 중고급 고급
4.4점 (8명)
좋아요 : 46

사전처럼 찾아 쓰는 REST API 규칙과 팁

사람들의 관심을 끌기 위해 경쟁하는 웹 서비스 시장에서, 잘 설계된 REST API는 꼭 지녀야 할 특징이 되고 있다. 이 책은 REST 아키텍처 스타일을 잘 살린, 실제 사례에서 도출한 REST API 디자인 규칙을 제공한다. REST API 규칙과 팁이 사전처럼 잘 정리되어 있으므로 필요한 부분만을 찾아서 사용할 수 있다. 제공하는 규칙에 따라 URI를 설계하면, 일관된 REST API를 웹 서비스에 적용할 수 있을 것이다.

대상 독자

웹 프로그래머, 웹 관리자

REST API를 사용하기 어려우신가요?
REST API는 웹 어디서나 볼 수 있지만, 그 중 일부만이 일관성 있는 설계 방법을 따르고 있다. 이는 REST API의 표준이 정해지지 않았기 때문이다. 그래서 많은 웹 프로그래머가 REST API를 어떻게 설계해야 할지 고민하고 있다. 이 책에서 설명하는 간단한 규칙들만 사용하면 웹 표준으로 인정받을 수 있는 웹 서비스 API를 설계할 수 있다. 저자인 마크 마세는 REST API를 설계하고 구현하기 위해 고안한 개념적 프레임워크인 WRML을 소개하여 일관성 있는 웹 서비스를 쉽게 설계할 수 있도록 도와준다.

저자

마크 마세

마크 마세는 ESPN의 엔지니어링 담당 시니어 엔지니어 디렉터로, 시애틀에 살고 있다. 월트디즈니사에서 14년 동안 엔지니어링, 관리, 아키텍처 관련 일을 하였으며 ESPN 스포츠 존, NFL.com, NASCAR 온라인 등에서 사용되는 인터랙티브 자바 애플릿을 개발하는 스타웨이브 사에서 경력을 쌓았다. 마크는 ESPN.com, ABC.com, Disney.com을 포함한 디즈니 웹 사이트에서 사용되는 콘텐츠 관리 시스템(CMS)을 설계하고 개발하였다. 2008년에는 웹 페이지를 생성하는 데 사용되는 데이터 모델을 결정하기 위한 시스템 및 방법을 개발하여 디즈니 발명상(Disney Inventor Award)을 수상하였다.
역자

권원상

서강대 컴퓨터공학과를 졸업했으며, 이포인트에서 웹 프로그램 개발 관련 일을 하다가, 현재는 디지털 방송 관련 솔루션을 개발하고 있다. 『IT 백두대간, 닷넷 프로그래밍: C#, VB.NET, ASP.NET』외 4권의 역서와 저서가 있다.
역자

김관래

삼성전자에서 웹 관련 프로젝트를 수행하였다. 서버단 REST API 디자인을 하였고, 프론트단 프로토타이핑과 테스트를 진행하였다. KT로 이직하여 ucloud open API 테스트와 SDK 제작에 참여하였다.
Flume 등 오픈 소스 관련한 스터디를 진행하고 있으며, 최근에는 R 언어 등을 이용한 데이터 프로세싱/비주얼라이제이션을 공부하고 있다. 아두이노와 같은 오픈 소스 하드웨어 플랫폼과 소프트웨어의 적절한 조합에도 관심이 많다. 지속 가능한 엔지니어링은, 문제를 해결함에 있어 "디자인+디벨롭먼트"의 조화로운 균형이라 생각하고 있다.

1장. REST 소개
  01 Hello World Wild Web
  02 웹 아키텍처
    클라이언트/서버 
    균일한 인터페이스 
    계층 시스템 
    캐시 
    상태 없음 5
    주문형 코드 
  03 웹 표준 
  04 REST
  05 REST API 
  06 REST API 설계
    규칙 
    WRML 
  07 정리
 
2장. URI 식별자 설계
  01 URI 13
  02 URI 형태 
    규칙: 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다 
    규칙: URI 마지막 문자로 슬래시(/)를 포함하지 않는다 
    규칙: 하이픈(-)은 URI 가독성을 높이는 데 사용한다 
    규칙: 밑줄( _ )은 URI에 사용하지 않는다 
    규칙: URI 경로에는 소문자가 적합하다 
    규칙: 파일 확장자는 URI에 포함시키지 않는다 
  03 URI 권한 설계 
    규칙: API에 있어서 서브 도메인은 일관성 있게 사용해야 한다 
    규칙: 클라이언트 개발자 포탈 서브 도메인 이름은 일관성 있게 만들어야 한다 
  04 리소스 모델링
  05 리소스 원형
    도큐먼트 
    컬렉션 
    스토어 
    컨트롤러 
  06 URI 경로 디자인 
    규칙: 도큐먼트 이름으로는 단수 명사를 사용해야 한다 
    규칙: 컬렉션 이름으로는 복수 명사를 사용해야 한다 
    규칙: 스토어 이름으로는 복수 명사를 사용해야 한다 
    규칙: 컨트롤러 이름으로는 동사나 동사구를 사용해야 한다 
    규칙: 경로 부분 중 변하는 부분은 유일한 값으로 대체한다 
    규칙: CRUD 기능을 나타내는 것은 URI에 사용하지 않는다 
  07 URI Query 디자인 
    규칙: URI 쿼리 부분으로 컬렉션이나 스토어를 필터링할 수 있다 
    규칙: URI 쿼리는 컬렉션이나 스토어의 결과를 페이지로 구분하여 나타내는 데 사용해야 한다 
  08 정리 
 
3장. HTTP를 이용한 인터랙션 설계
  01 HTTP/1.1 
  02 요청 메서드
    규칙: GET 메서드나 POST 메서드를 사용하여 다른 요청 메서드를 처리해서는 안 된다 
    규칙: GET 메서드는 리소스의 상태 표현을 얻는 데 사용해야 한다 
    규칙: 응답 헤더를 가져올 때는 반드시 HEAD 메서드를 사용해야 한다 
    규칙: PUT 메서드는 리소스를 삽입하거나 저장된 리소스를 갱신하는 데 사용해야 한다 
    규칙: PUT 메서드는 변경 가능한 리소스를 갱신하는 데 사용해야 한다 
    규칙: POST 메서드는 컬렉션에 새로운 리소스를 만드는 데 사용해야 한다 
    규칙: POST 메서드는 컨트롤러를 실행하는 데 사용해야 한다 
    규칙: DELETE 메서드는 그 부모에서 리소스를 삭제하는 데 사용해야 한다 
    규칙: OPTIONS 메서드는 리소스의 사용 가능한 인터랙션을 기술한 메타데이터를 가져오는 데 사용해야 한다
  03 응답 상태 코드 
    규칙: 200("OK")는 일반적인 요청 성공을 나타내는 데 사용해야 한다 
    규칙: 200("OK")는 응답 바디에 에러를 전송하는 데 사용해서는 안 된다 
    규칙: 201("Created")는 성공적으로 리소스를 생성했을 때 사용해야 한다 
    규칙: 202("Accepted")는 비동기 처리가 성공적으로 시작되었음을 알릴 때 사용해야 한다 
    규칙: 204("No Content")는 응답 바디에 의도적으로 아무것도 포함하지 않을 때 사용한다 
    규칙: 301("Moved Permanently")는 리소스를 이동시켰을 때 사용한다 
    규칙: 302("Found")는 사용하지 않는다 
    규칙: 303("See Other")은 다른 URI를 참조하라고 알려줄 때 사용한다 
    규칙: 304("Not Modified")는 대역폭을 절약할 때 사용한다 
    규칙: 307("Temporary Redirect")은 클라이언트가 다른 URI로 요청을 다시 보내게 할 때 사용해야 한다 
    규칙: 400("Bad Request")은 일반적인 요청 실패에 사용해야 한다 
    규칙: 401("Unauthorized")은 클라이언트 인증에 문제가 있을 때 사용해야 한다 
    규칙: 403("Forbidden")은 인증 상태에 상관없이 액세스를 금지할 때 사용해야 한다 
    규칙: 404("Not Found")는 요청 URI에 해당하는 리소스가 없을 때 사용해야 한다 
    규칙: 405("Method Not Allowed")는 HTTP 메서드가 지원되지 않을 때 사용해야 한다 
    규칙: 406("Not Acceptable")은 요청된 리소스 미디어 타입을 제공하지 못할 때 사용해야 한다
    규칙: 409("Conflict")는 리소스 상태에 위반되는 행위를 했을 때 사용해야 한다 
    규칙: 412("Precondition Failed")는 조건부 연산을 지원할 때 사용한다 
    규칙: 415("Unsupported Media Type")은 요청의 페이로드에 있는 미디어 타입이 처리되지 못했을 때 사용해야 한다 
    규칙: 500("Internal Server Error")는 API가 잘못 작동할 때 사용해야 한다 
  04 정리
 
4장. 메타데이터 디자인
  01 HTTP 헤더 
    규칙: Content-Type을 사용해야 한다 
    규칙: Content-Length를 사용해야 한다 
    규칙: Last-Modified는 응답에 사용해야 한다 
    규칙: ETag는 응답에 사용해야 한다 
    규칙: 스토어는 조건부 PUT 요청을 지원해야 한다 
    규칙: Location은 새로 생성된 리소스의 URI를 나타내는 데 사용해야 한다 
    규칙: Cache-Control, Expires, Date 응답 헤더는 캐시 사용을 권장하는 데 사용해야 한다 
    규칙: Cache-Control, Expires, Pragma 응답 헤더는 캐시 사용을 중지하는 데 사용해야 한다 
    규칙: 캐시 기능은 사용해야 한다 
    규칙: 만기 캐싱 헤더는 200("OK") 응답에 사용해야 한다 
    규칙: 만기 캐싱 헤더는 '3xx' 와 '4xx' 응답에 선택적으로 사용될 수 있다 
    규칙: 커스텀 HTTP 헤더는 HTTP 메서드의 행동을 바꾸는 데 사용해서는 안 된다 
  02 미디어 타입
    미디어 타입 문법 
    등록된 미디어 타입 
    벤더 고유 미디어 타입 
  03 미디어 타입 설계 
    규칙: 애플리케이션 고유 미디어 타입을 사용해야 한다 
    규칙: 리소스의 표현이 여러 가지 가능할 경우 미디어 타입 협상을 지원해야 한다 
    규칙: query 변수를 사용한 미디어 타입 선택을 지원할 수 있다 
  04 정리
 
5장. 표현 디자인
  01 메시지 바디 포맷 
    규칙: JSON 리소스 표현을 지원해야 한다 
    규칙: JSON은 문법에 잘 맞아야 한다 
    규칙: XML과 다른 표현 형식은 선택적으로 지원할 수 있다 
    규칙: 추가 봉투는 없어야 한다 
  02 하이퍼미디어 표현 
    규칙: 링크는 일관된 형태로 나타내야 한다 
    규칙: 링크 관계를 표현할 때에는 일관된 형태를 사용해야 한다 
    규칙: 링크를 표현할 때는 일관된 형태를 사용해야 한다 
    규칙: 응답 메시지 바디 표현에 셀프 링크를 포함해야 한다 
    규칙: 진입 API URI 수를 최소화하라 
    규칙: 리소스의 상태에 따라 가능한 액션을 표현하기 위해서 링크를 사용해야 한다 
  03 미디어 타입 표현 
    규칙: 미디어 타입 format은 일관성 있는 폼을 사용해야 한다 
    규칙: 미디어 타입 스키마를 표현할 때는 일관성 있는 형식을 사용해야 한다 
  04 오류 표현 
    규칙: 오류는 일관성 있게 표현한다 
    규칙: 오류 응답은 일관성 있게 표현한다 
    규칙: 일반적인 오류 상황에서는 일관성 있는 오류 타입을 사용해야 한다 
  05 정리 
 
6장. 클라이언트 영역
  01 개요
  02 버전을 정의하는 방법
    규칙: 새로운 개념을 도입하려면 새로운 URI를 사용해야 한다 
    규칙: 표현 형태의 버전을 관리하기 위해서는 스키마를 사용해야 한다 
    규칙: 엔티티 태그는 표현 상태 버전을 관리하기 위해 사용한다 
  03 보안
    규칙: 리소스 보호를 위해 OAuth를 사용할 수 있다 
    규칙: 리소스 보호를 위해 API 관리 솔루션을 사용할 수 있다 
  04 응답 표현 조합 
    규칙: URI의 쿼리 부분은 부분 응답을 지원할 때 사용해야 한다 
    규칙: URI 쿼리 부분은 연결된 리소스를 포함할 때 사용해야 한다
  05 하이퍼미디어 처리 
  06 자바스크립트 클라이언트 
    규칙: 자바스크립트에서 여러 웹 사이트에 읽기 접근이 가능하도록 JSONP를 지원해야 한다 
    규칙: 자바스크립트에서 여러 웹 사이트에 읽기/쓰기 접근이 가능하도록 CORS를 지원해야 한다 
  07 정리 
 
7장. 마지막 생각
  01 최고의 수준 
  02 일관된 구현 
    원리: REST API 설계는 필요 이상으로 다르다 
    원리: REST API는 구현되는 것이 아니라 설계되어야 한다 
    원리: 프로그래머와 그들 조직의 일관성은 도움이 된다
    원리: REST API는 GUI 도구로 만들어진다 
  03 정리 
 
Appendix
  나의 첫 번째 REST API

  • REST API를 설계하기 위한 디자인 규칙으로 REST API 개요부터 해서, 각 카테고리 별 디자인 규칙과, 저자의 경험이 녹아든 에세이 까지 흥미로운 형태(?)로 구성되어 있다.

    REST API를 잘 아는 사람은, 상세하게 기술되어 있는 제목을 바탕으로 원하는 부분만 집어서 볼 수 있도록 구성되어 있으나,

    본인은 얕은 REST API 경험을 가지고 있으므로 천천히 시간내서 읽어 보면서 이것저것 많은 도움이 되었던 것 같다.

    역시 프로그래밍 언어는 비슷한 점이 많아서, 디자인 규칙은 비슷한 점이 많았지만....
    REST 와 연계되어 있는 다른 설명들도 많이 있고, 또 그에 관련된 자료들도 주석으로 링크 되어있었으므로, 여기저기 다녀보면서 재미있게 읽었다.

    다만, 나는 번역서의 번역은 어차피 매끄럽지 못하기 때문에 크게 기대를 안하는 편인데도, 어색한 부분이 많았다고 생각되는 점이 안타까웠으나....

    REST API를 처음 설계해보는 분들은 꼭 한번 읽어보았으면 하는 책이다.

  • 최근 openapi 를 제공하는 서비스들이 많아지고 있습니다. 그리고 openapi가 언급될때 보통 같이 언급되는게 REST 방식으로 API 를 제공한다는 얘기도 많이 들려옵니다.
    REST를 통해서 XML(혹은 JSON)과 HTTP를 사용하는 단순한 웹 기반 인터페이스를 제공할 수 있습니다.

    API의 I가 의미하는 인터페이스라는건 서로간의 지켜야할 약속입니다.
    웹서비스를 제공하는 서버측은 양질의 서비스를 쉽고 잘 설계된 API를 제공해야 더 많은 클라이언트 개발자를 불러모을 수 있을것이고,
    클라이언트 개발자는 제공받는 API를 정확한 의도에 맞게 사용함으로써 양질의 소프트웨어를 만들어 낼 수 있게 됩니다.

    이 책은 REST API를 만들기 위한 설계 원칙들을 설명해주고 있습니다.

    도입부는 용어 정의/설명으로 되어 있는데 좀 지루한 감이 있긴하지만 뭐 용어를 알아야 문장도 이해하고 그런거니 이해해야겠죠

    본문은 "~~하는 게 좋다. ~~하지 말라" 식의 규칙이 나오고 규칙에 대한 간략한 설명과 예시 (예시는 있는 것도 있고, 없는 것도 있고)가 반복되는 구조인데
    FAQ나 사전식으로 필요한 정보를 골라 활용하는 형태로 되어 있습니다.

    좋은 API를 설계하는 방법에 대해 잘 나와있고 각 챕터 끝부분에는 내용을 요약해 주는 정리파트가 있어서 좋았습니다.
    하지만 따라할 수 있는 코드가 있는 CookBook 스타일의 책이 아니기 때문에 실제로 RESTAPI를 설계하거나 사용해본 사람이 아닌 저 같은 사람보다는
    현재 REST API를 사용하는 사람들에게 더 도움이 될 거 같습니다. 하지만 나중에라도 REST API를 만들게 된다면 든든한 가이드가 될 거 같습니다.

    용어정리쪽에 나오는 설명들의 번역은 아무래도 영 어색하네요. 번역이 잘됐다 잘못되었다의 의미가 아니라 영어가 더 익숙한 느낌이랄까
    요청/응답/표현보다 request/response로 읽어야 머릿속으로 잘 읽힌다는 불편함등이 좀 있네요.

  • REST API를 설계하거나 사용해본 개발자라면 한번쯤 고민하고 찾아 봤을법한 알찬 내용들로 구성되어 있습니다. 이런 경우는 어떻게 설계하는게 좋을까? 구글이나 facebook 등의 Open API를 보면서 왜 이렇게 설계를 했을까? 고민을 해본 사람이라면 이 책을 통해 그 궁금증이 어느정도 해소될거라 생각됩니다.
    설명이 자세한 편은 아니지만, REST API의 개념을 명확하게 집어주고 어떤 방향으로 설계를 해야 되는지 Guide 하는데 충분한것 같습니다.
    그리고 분량이 많지 않아 읽기에 부담스럽지 않고 PDF파일로 필요할때 언제든지 다운 받아서 볼수 있어서 좋네요.

  • Rest는 SOAP과 같이 표준이 없기 때문에 구현이 매우 자유롭지만,

    Resource를 URL과 HTTP Method등의 단순한 규칙들로 표현해야 하기 때문에 잘 설계하기 위해서는 구현과정중 다양한 시행착오를 겪을 수 있습니다.

    이 책은 URI설계, HTTP Method/Header/Status, WRML 등 일반적으로 사용되는 REST API Modeling 규칙들을 담고 있어 여러번 읽고 숙지하면 일관된 API설계하는데 매우 도움이 될 것이라고 생각합니다.

    페이지수가 많지않아 간단하게 읽기에 부담스러운 수준은 아닌데, 다양한 규칙을 담고 있어 API 설계시에 참고하면 좋습니다.


    당장 REST를 설계해야 한다면 꼭 정독을 권하고 싶고, 같이 읽어볼만 한 문서도 있는데 참고 바랍니다.
    http://blog.apigee.com/detail/announcement_new_ebook_on_web_api_design/

  • 제가 이 책을 알게된 것은 잘 아는 지인이 요즘 웹 프로그래밍 추세가 어떤지 잘 확인해보라는 애정어린 조언과 함께 이 책을 한 번 보라는 추천에 의해서였습니다.

    "사전처럼 찾아쓰는 ~ "형태의 종이 책은 몇 권 소지하고 있고, 프로그래밍이나 오피스 작업을 할 때 유용하게 참고하고 있었기에 이 책도 정독하기보단 여러번 읽는 형태로 보았습니다.

    그런데 앞서 본 종이책과 확연하게 비교되는 점이 있었습니다.
    책의 초반부를 보고있더라도 그 항목이 뒷 부분에서 상세히 나오면 책을 뒤로 넘겼다가 다시 보던 부분으로 넘어가야하는 번거로움이 있었습니다. 그런데, 리얼타임으로 볼 때는 그냥 클릭 한 번이면 링크된 부분으로 바로 이동했다가 다시 보던 부분으로 이동이 가능하니 시간절약도 되고 번잡하지 않더라구요.

    일단, 책 자체의 내용은 크게 어렵지도 쉽지도 않습니다. 저같이 REST API라는건 뭔지는 알겠는데 이걸 어떻게 적용을 해야하나 싶은 분은 계속 읽어보면서 궁금한 것은 따로 메모해두었다가 검색하면서 찾는 방식으로해서 천천히 익혀나가시는게 좋을듯 싶습니다. 사실 전 아직.. 이 책을 사전처럼 찾아쓰지 못하고 그저 개념체득용으로 쓰고 있기에 ^^;..

  • 대입전형이 너무 다양한 까닭에 입시 컨설팅이 흥한다고 한다. 저자가 책 말미에 언급하듯이 REST API를 작성하는 것도 그 만큼 다양항 프레임워크/방식이 존재하는데 이 책은 현재 상황에서 어떻게 하면 좋은 API를 작성할 수 있는지 친절하게 알려주는 컨설턴트 같다.

    7페이지에 이르는 차례는 다양한 규칙을 열거하고 있는데, 규칙이 명확하게 기술되어 있어서 틈틈이 차례만 읽어 보아도 많은 도움이 될 것 같다.

    덤으로 HTTP 요청과 응답을 적절하고 정확하게 이용하는 방법에 대해 다루고 있어서 REST API를 다루면서 HTTP를 한 번 더 살펴볼 수 있는 좋은 기회를 제공하고 있다.

    일부 어색한 용어와 실제 동작하는 예제(API와 CLIENT)가 없어서 REST API에 익숙하지 않는 경우에는 후반부로 갈 수록 난해한 느낌이 든다는 점이 아쉽긴 하지만 책에서 일러주는 규칙들 만으로도 충분히 의미가 있는 책이다.

  • 페이스북, 트위터, 구글 아마 일반적으로 우리가 아는 대부분의 트래픽은 위의 업체들에 집중되고 있을 것입니다. 뭐, 구글이야 조금 다르긴 하지만, 페이스북과, 트위터가 왜 이렇게 성장했을까요? 그리고 현재 구글에서 그토록 노력하는 것중에 하나가 구글+로의 통합인데, 그러기 위해서 어떤 정책을 내놓고 있을까요?

    그게 바로 Open API입니다. 자신들의 서비스를 외부에서 자유롭게 가져다가 쓸 수 있도록 하는 것, 당연히 기능도 좋아야 겠지만, 다음과 같은 몇가지 특성을 가져야 합니다.
    1. 사용하기 쉬움
    - REST API가 왜 각광을 받는가 하면, 기존의 다른 형태로 제공하는 것보다 훨씬 사용하기 쉽기 때문입니다. 웹 서버는 어디서나 사용할 수 있고, json은 대부분의 언어에서 사용하기 쉽습니다.
    2. 일관성
    - 사용하기 쉽다는 것은 또한 일관성을 가진다는 것입니다. REST API를 단순히 인터페이스만 만드는 것으로 착각하면 큰 코 다칩니다. 응답의 일관성, URI 작성의 일관성등, 알아야 할 많은 규칙들이 있습니다.

    그런 내용들을 이 책에서는 약간의 룰 북 또는 지침서 같은 형태로 알려줍니다. 다만, 페이지수가 한번에 보고 이해할 정도가 아니고, 외우고, 이해해야할 내용들이 많으므로, 오래 두고두고 봐야할 것 같습니다.

  • REST 는 요즘의 웹에서 흔히 사용되지만 API 설계시 어떤 규칙을 따라야 하는지는 특별하게 가이드해주는 책은 없었던 것 같다. 그런 의미에서 이 책은 가려운 곳을 긁어주는 유용한 가이드 이다. 영어에 울렁증을 느끼는 많은 개발자를 위해 깔끔한 번역과 보기 좋은 레이 아웃으로, 그것도 어디서나 다운 받아 활용할 수 있는 DRM free PDF 타입의 ebook으로 나온 것도 환영할 일이다. (특히 아이패드 레티나로 보니 환상..)

결재하기
• 문화비 소득공제 가능
• 배송료 : 0원배송료란?

배송료 안내

  • 책, 아이템 등 상품을 3만원 이상 구매시 무료배송
  • 브론즈, 실버, 골드회원이 주문하신 경우 무료배송

무료배송 상품을 포함하여 주문하신 경우에는 구매금액에 관계없이 무료로 배송해 드립니다.

닫기

리뷰쓰기

닫기
* 도서명 :
일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙
* 제목 :
* 별점평가
* 내용 :

* 리뷰 작성시 유의사항

글이나 이미지/사진 저작권 등 다른 사람의 권리를 침해하거나 명예를 훼손하는 게시물은 이용약관 및 관련법률에 의해 제재를 받을 수 있습니다.

1. 특히 뉴스/언론사 기사를 전문 또는 부분적으로 '허락없이' 갖고 와서는 안됩니다 (출처를 밝히는 경우에도 안됨).
2. 저작권자의 허락을 받지 않은 콘텐츠의 무단 사용은 저작권자의 권리를 침해하는 행위로, 이에 대한 법적 책임을 지게 될 수 있습니다.

오탈자 등록

닫기
* 도서명 :
일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙
* 구분 :
* 상품 버전
종이책 PDF ePub
* 페이지 :
* 위치정보 :
* 내용 :

도서 인증

닫기
도서명*
일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙
구입처*
구입일*
부가기호*
부가기호 안내

* 회원가입후 도서인증을 하시면 마일리지 500점을 드립니다.

* 한빛 웹사이트에서 구입한 도서는 자동 인증됩니다.

* 도서인증은 일 3권, 월 10권, 년 50권으로 제한됩니다.

* 절판도서, eBook 등 일부 도서는 도서인증이 제한됩니다.

닫기

해당 상품을 장바구니에 담았습니다.이미 장바구니에 추가된 상품입니다.
장바구니로 이동하시겠습니까?

자료실