본문 바로가기

리디 접속이 원활하지 않습니다.
강제 새로 고침(Ctrl + F5)이나 브라우저 캐시 삭제를 진행해주세요.
계속해서 문제가 발생한다면 리디 접속 테스트를 통해 원인을 파악하고 대응 방법을 안내드리겠습니다.
테스트 페이지로 이동하기

[리얼타임] 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙 상세페이지

컴퓨터/IT 개발/프로그래밍

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

소장전자책 정가11,000
판매가10%9,900
[리얼타임] 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙 표지 이미지

리디 info

도서 이용 안내
서점에서 판매 중인 리얼타임 시리즈는 DRM-Free 도서가 아닙니다.
DRM-Free 도서는 한빛미디어 홈페이지에서 별도 구매하셔야 합니다.
도서 이용에 참고 부탁드립니다.


[리얼타임] 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙작품 소개

<[리얼타임] 일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙> "사전처럼 찾아 쓰는 REST API 규칙과 팁

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

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


저자 프로필

마크 마세 Mark Massé

  • 경력 ESPN 엔지니어링 담당 시니어 엔지니어 디렉터
  • 수상 디즈니 발명상(Disney Inventor Award)

2015.05.15. 업데이트 작가 프로필 수정 요청


저자 소개

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


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


[옮긴이] 권원상
남들보다 쉽게, 명쾌하게 IT 지식을 설명할 수 있는 사람'배우고 알게 된 것을 다른 사람과 나누는 것을 좋아한다. 지난 십 수년간 교육용 CD-ROM 타이틀에서 웹 사이트, 디지털 아카이브 시스템, 홈 네트워크까지 여러 분야에서 개발자로 일 해왔다. 최근 몇 년간은 파워포인트로 일하는 시간이 많아서, 스스로에게 아쉬워할 때가 많다. 컴퓨터에서 발생하는 오류보다 사람 사이에 발생하는 오해가 훨씬 더 해결하기 어려울 때가 많다는 것을 매일매일 확인하며 살고 있다."

목차

"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"


리뷰

구매자 별점

3.8

점수비율
  • 5
  • 4
  • 3
  • 2
  • 1

9명이 평가함

리뷰 작성 영역

이 책을 평가해주세요!

내가 남긴 별점 0.0

별로예요

그저 그래요

보통이에요

좋아요

최고예요

별점 취소

구매자 표시 기준은 무엇인가요?

'구매자' 표시는 리디에서 유료도서 결제 후 다운로드 하시거나 리디셀렉트 도서를 다운로드하신 경우에만 표시됩니다.

무료 도서 (프로모션 등으로 무료로 전환된 도서 포함)
'구매자'로 표시되지 않습니다.
시리즈 도서 내 무료 도서
'구매자’로 표시되지 않습니다. 하지만 같은 시리즈의 유료 도서를 결제한 뒤 리뷰를 수정하거나 재등록하면 '구매자'로 표시됩니다.
영구 삭제
도서를 영구 삭제해도 ‘구매자’ 표시는 남아있습니다.
결제 취소
‘구매자’ 표시가 자동으로 사라집니다.

Realtime


[리얼타임]


이 책과 함께 구매한 책


이 책과 함께 둘러본 책



본문 끝 최상단으로 돌아가기

spinner
모바일 버전