[TIL] 오늘 정리, Restful API 공부
오늘 공부
[O] : 알고리즘 페어프로그래밍 2문
[△] : 장고 강의 듣기! | 오후나 저녁
- [O] : 심화 3주차 JWT토큰 다시 듣기
- [△] : 4주차 듣기
[O] : 개인과제 시작 | 오후나 저녁
- [O] : todo list ERD | 10시 반 ~ 11시 반
- [O] : todo list 클론코딩으로 회원가입기능 재구현하기
[O] : 장고 MVT 강의 at 8pm
복습한 것
1) JWT토큰 강의를 다시 들었다.
- 토큰설정이나 POST로 토큰을 주고받을 때 자꾸 500 error가 나서.. 원인 파악 중이다
- 혹시 오타가 있는지 확인차, 복습 겸 겸사겸사 다시 공부해보았다.
- error 나는 부분: token 설정 후
cors-hearders 기능을 설치, 적용 및 True설정을 해주었는데도 작동하지 않음
#settings.py
CORS_ALLOW_ALL_ORIGINS = True
[참고하여 해결하기] :
더 알게 된 것
- Restful API에 대한 공부
- HTTP 공부를 하면서 아래와 같이 restful api를 가볍게 짚고 넘어갔었는데,
막상 과제를 하며 코드를 작성하려고 보니 어떻게 해야할지 막막한 기분이 들어 기초를 채우기 위해 추가로 공부해보았다.
가장 중요한 것은 리소스 식별임.
|
Restful API를 알아보자
공식문서에 따르면,
RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
비즈니스 애플리케이션은 다양한 태스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신하는데,
그런 통신의 과정에서 Restful API를 사용함으로써 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신을 지원한다.
-> 아니 이게 무슨말이야.. 라고 생각된다면
Restful 과 API, 그리고 앱 간의 통신에 대한 기반 지식이 부족한 것이다.. = 공부가 더 필요^.^
Rest
- Representational State Transfer(REST)
직역하면 '대표 상태 전송' - HTTP를 활용할 수 있는 아키텍쳐로, HTTP 요청을 보낼 때 어떤 URI에 어떤 메소드를 사용할지, 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하도록 하기 위해 개발자들 사이에 널리 지켜지는 약속
- 정보들을 주고받는데 쓰이는 일종의 형식
API
- application programing interface
** API의 맥락에서
application은 고유한 기능을 가진 모든 소프트웨어
interface는 두 애플리케이션 간의 서비스 계약
이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의한다.
API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있다! - 그러니까 간단히말하면, 두 소프트웨어가 통신하는 매커니즘이 API
- 웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이
- 클라이언트 = 사용자 / 리소스 앱이 사용자에게 제공하는 정보
그러니까,
Restful API란 두 애플리케이션이 통신하는데 있어 일종의 형식/약속이 있는 매커니즘!
REST API = RESTful한 API = HTTP 통신 시 REST 원리를 따르는 API
Restful API의 장점
- 확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화 = 효율적 크기 조정 - 유연성
완전한 클라이언트-서버 분리를 지원 = 각 부분이 독립적으로 발전할 수 있음
애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다.
예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다! - 독립성
API 설계에 영향을 주지 않고 클라이언트, 서버앱 모두 작성 / 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경
디자인 가이드
1. URI는 정보의 자원을 표현해야 한다.(동사 쓰지않기!)
path('signup/', views.UserView.as_view(), name='signup'),
path('article_index/', views.ArticleView.as_view(), name='article_view'),
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
기억해야할 중요 포인트
- “RESTful“한 API 설계에서 시스템에서 제공하는 것들은 Resource라고 말하며 URL로 표기 한다!
- Resource를 명사(noun)적 특성을 갖도록 작성하기
- Restful API를 모든 상황에 반드시 적용해야하는 것은 아니다!
[참고] :
https://aws.amazon.com/ko/what-is/api/
API란 무엇인가요? - 애플리케이션 프로그래밍 인터페이스 설명 - AWS
GraphQL은 API용으로 특별히 개발된 쿼리 언어로서, 클라이언트에게 요청한 데이터만 제공하는 것을 우선으로 합니다. 또한 API를 빠르고 유연하며 개발자 친화적으로 만들도록 설계되었습니다. RES
aws.amazon.com
https://aws.amazon.com/ko/what-is/restful-api/
RESTful API란 무엇인가요? - RESTful API 설명 - AWS
Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다. API Gateway를 사용하면 실시간 양방향 통신 애
aws.amazon.com
+ [참고] : 튜터님이 주신 링크들
RESTful API 에 관해서 한 번 보시면 도움이 될 수 있어서 공유합니다.
restful이 정답이 아니지만 복잡하지 않은 로직이나 명료한 부분에서는 사용해도 좋기에 한번보시고 적용해보셔도 좋습니다
https://meetup.nhncloud.com/posts/92
https://beyondj2ee.wordpress.com/2013/03/21/%EB%8B%B9%EC%8B%A0%EC%9D%98-api%EA%B0%80-rest[…]C%95%8A%EC%9D%80-5%EA%B0%80%EC%A7%80-%EC%A6%9D%EA%B1%B0/
velog.io
REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 (180kB)
NHN Cloud Meetup
REST API 제대로 알고 사용하기 : NHN Cloud Meetup
REST API 제대로 알고 사용하기
최근에 “Lorna Mitchell” 라는
“Five Clues That Your API isn’t RESTful (당신의 API가 RESTful 하지 않는 5가지 증거)”
의 내용을 기본으로 저의 견해를 덧붙여서 재구성 해봤습니다.
참고로 “Lorna Mitchell” 여성 PHP 개발자 이면서, 특히 API 디자인에 대해서
좋은 아이디… 자세히 표시
이전 학습내용을 바탕으로 내일 하고 싶은 것
- 함께 알고리즘 페어프로그래밍 할만한 문제 찾아두기
(이번 우리 조는 실력이 엇비슷한 것 같다! 좋다!)
- cors-headers문제 해결하기,,
- 개인과제 웬만하면 기본 기능 완성하고 테스팅하기
- 1차로 과제 완성후 시간이 있으면 클론 코딩 말고, 직접 작성하면서 Serializer와 generic에 익숙해지면 좋겠다
느낀점:
컴퓨터공학...@_@
공부는 열심히 한 것 같은데 머리에 남은 것은 왠지 없는 듯한 하루...
아마 마무리된 것이 없어서 그런 것 같다.
내일은 무언가 마무리하거나 완성해보는 하루를 보내야지!