티스토리 뷰
1. REST API란.
기존에 제가 만들었던 Back-end 들을 보면 프로토콜이 어떤 목적으로 보내는지 몰랐습니다.
물론 제가 만들었던 프로젝트들이니 코드를 뜯어보면 제가 무슨 목적으로 맵핑을 했는지
알 수 있었지만, 정확한 목적을 가지고 프로토콜을 보내진 않았습니다.
REST API는 일련의 과정들에서 내가 보내는 프로톨이 무슨 목적인지 정확하게 정의 해줍니다.
우리가 알고 있는 CRUD는 다음과 형태를 띄웁니다.
C = POST
R = GET
U = PUT or PATCH
D = DELETE
REST api 는 프로토콜을 보낼때 C인지 D인지 등 정확하게 목적을 가지고 이동하도록 하는 방식입니다.
그럼 정확하게 REST api 의 설계방법은 무엇일까요
간단하게 설명하면 REST 의 규칙을 준수한 api를 REST api 라고 명칭하기로 했어요
1. 그럼 왜 사용해야 하나요?
REST api 의 장점을 먼저 살펴봐야 합니다.
- HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
- HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
- 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
여러 장점이 있지만, 간단하게 요약하면
REST api는 기존의 HTTP 프로토콜과 비슷한 형태를 따르기 때문에,
범용성이 뛰어나고, 서버와 클라이언트를 분리해 역할을 구분할 수 있다.
라고 생각하면 될 것 같습니다.
반대로 단점도 몇가지 존재 합니다.
- 표준이 자체가 존재하지 않아 정의가 필요하다.
- 사용할 수 있는 메소드가 4가지밖에 없다.
- HTTP Method 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)
단점은 참고 정도만 해주세요.
3. 설계 예시
- URL에 동사보다는 명사를, 대문자 보다는 소문자를 사용하는 방식
잘못된 설계 : http://ggparkitbank.tistory.com/Running # 동사 사용 & 대문자
올바른 설계 : http://ggparkitbank.tistory.com/run
- 마지막에 ( / ) 포함하지 않을 것
잘못된 설계 : http://ggparkitbank.tistory.com/run/
올바른 설계 : http://ggparkitbank.tistory.com/run
- 언더바 대신 하이폰을 사용
-일반적으로 개발자 분들은 언더바를 많이 사용해서 이 부분이 헷갈릴 거 같네요
잘못된 설계 : http://ggparkitbank.tistory.com/run_run
올바른 설계 : http://ggparkitbank.tistory.com/run-run
- 파일확장자는 URL에 포함 X
잘못된 설계 : http://ggparkitbank.tistory.com/run.jpg
올바른 설계 : http://ggparkitbank.tistory.com/run
- 역할 or 행위를 표현하지 않을 것
잘못된 설계 : http://ggparkitbank.tistory.com/delete-post/run
올바른 설계 : http://ggparkitbank.tistory.com/post
이렇게 간단하게 REST API에 대한 이론을 알아봤습니다.
REST를 사용한다 해서 REST API 인 것은 아닙니다. 규칙에 맞춰서
정확하게 작성을 완료 했을때 비로소 REST API 로 인정받을 수 있습니다.
다음에는 Spring 을 활용해서 REST API 를 구축 해보도록 하겠습니다.
- Total
- Today
- Yesterday
- rabbitmq
- prometheus
- consumer
- Spring + ELK
- LoadBalancer
- ACTUATOR
- Kafka Connect
- git
- 루틴기록
- config
- github
- elasticSearch
- Logstash 활용
- 운동
- kafka
- zipkin
- Logstash to ElasticSearch
- 오늘저녁 삼겹살
- 미래의나에게동기부여
- MSA
- UserService
- docker
- 운동일기
- Gateway
- JWT
- producer
- Feign
- MariaDB
- 빅-오
- springcloud
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |