RESTful API 피드백

목표 D-day : 43 일

학습목표

• RESTful API에 대해서 학습하기

• 그리고 피드백 하기

API

API는 소프트웨어 간의 기능을 사용하기 위해서 미리 정의된 규칙입니다.

API를 사용하여 컴퓨터 소프트웨어의 기능을 실행할 수 있습니다.

RESTful API

HTTP를 이용해서 소프트웨어끼리 통신을 할 때 명확하면서 단순하게 통신을 하기 위한 약속입니다.

HTTP는 RESTful API의 필수요소는 아니지만 RESTful API의 조건을 구현하기 편하기 때문에 주로 사용합니다.

URI는 리소스를 식별하기 위한 주소입니다.

테블릿

id	모델	상세내역
1	galaxy-tab-s10	…
2	galaxy-tab-s9	…
3	galaxy-tab-s8	…

URI는 식별할 수 있는 리소스로 작성됩니다.

테블릿을 모두 의미하는 경우 URI는 /samsung/tablets

테블릿안에 s10을 /samsung/tablets/1으로 id를 통해서 나타낼 수 있습니다. 만약 id가 아니라 모델명이 고유하고, 변하지 않는 식별자로 사용할 수 있다면 id가 아니여도 됩니다. /samsung/tables/galaxy-tab-s10

리소스를 URI로 표현해도 의미가 없습니다. URI는 그 리소스를 식별하는 이름일 뿐입니다.

이 정보를 가공할 수 있어야합니다.

method

리소스를 사용하고 가공하기 위해서는 Create,Read,Update,Delete내에서 사용할 수 있습니다.

HTTP에서는 리소스를 사용하고 가공하기 위해서 HTTP method를 이용해서 표현할 수 있습니다.

Create - POST,Read - GET,Update - PUT,PATCH,Delete - DELETE로 리소스에 대한 작업 내용을 정의할 수 있습니다.

HTTP 메소드를 본래 용도에 맞게 사용하는 것이 REST API에서 중요합니다.

장점

HTTP 프로토콜을 기반으로 설계되어있어 직관적이고 이해하기 쉽습니다.

브라우저와 서버나 서버와 서버끼리 통신에서 사용할 수 있으므로 유연하고 확장하기 편합니다.

HTTP의 캐싱 메커니즘을 사용하여 응답을 캐시할 수 있습니다.

한계

복잡한 트랜잭션 처리에서 여러 리소스 간의 복잡한 트랜잭션처리하는데 어려움이 있습니다.

주문 처리 시스템은 다음과 같은 트랜잭션으로 만들어졌습니다.

1. 주문 생성
2. 포인트 감소
3. 쿠폰 삭제

RESTful API로 표현한다면

POST /orders -> 새로운 주문 생성
PUT /buyer/{buyerId} -> 포인트 업데이트
DELETE /coupons/{couponId} -> 주문자 쿠폰 삭제

이렇게 표현해야합니다.

이런 경우 RESTful API는 리소스 마다 독립적으로 처리해야하지만 트랜잭션으로 요청해야하는 경우에는 RESTful API로 표현하기 어렵습니다.

관리하기 어렵다

REST 아키텍처의 특징은 암묵적인 규칙입니다.

표준이 존재하지 않기 때문에 특정 메서드를 사용하지 않거나, HTTP 상태코드 일부를 사용하지 않는 경우도 있습니다.

• 추가로 학습할 자료
• 구글 API