서버로 데이터를 보내기
여기에서는 앞에서 만들어낸 중요한 데이터들을 서버로 보내는 역할을 하게 됩니다. 예전에는 백엔드를 개발하던 사람이 본인의 API를 테스트를 하면서 작업을 하던 영역이었지만 이제는 완전히 프론트엔드로 분리가 되어버린 부분입니다. 웹 디자인을 주로 하던 분들이 막히는 곳이기도 합니다. 혼자서만 공부를 하기 애매한 영역이기 때문이죠. 웹의 가치는 데이터의 공유와 유통에 있기 때문에 점점 더 중요해지고 있습니다.
백엔드로 데이터를 전달하는 작업 자체는 정말로 어렵지가 않은데도 이 부분이 어려운 이유는 이 작업이 백엔드에 의존성이 있기 때문입니다. 인증, 보안, 헤더, CORS 등 백엔드에서 만들어둔 설정에 따라 맞춰서 작업을 해야 하는데, 이것들은 코딩의 영역이 아니라 학습의 영역이고 협업의 영역이라 백엔드와 적절히 협업을 할 수 있을 정도의 CS 능력이 필요합니다. 대표적으로 HTTP 프로토콜과 REST API의 간단한 이해정도가 있겠네요.
특히 문제가 생겼을 때 프론트엔드의 문제인지 백엔드의 문제인지 판단을 할 수도 있어야 대응이 가능하므로 협업의 경험치 축적이 필요한 영역입니다.
세부적인 내용은 다음과 같습니다.
|
REST API이 대부분의 작업이나 GrpahQL이나 RPC, Web Socket, Web RTC 스트리밍 등 데이터 교환에는 여러 분야들이 존재하니 개발하는 영역에 따른 추가 공부가 필요합니다.
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
"REST API이 대부분의 작업이나 GrpahQL이나 RPC, Web Socket, Web RTC 스트리밍 등 데이터 교환에는 여러 분야들이 존재하니 개발하는 영역에 따른 추가 공부가 필요합니다."
https://www.boostcourse.org/web316/lecture/16740
클라이언트의 종류가 웹 브라우저, 안드로이드 앱, iOS 앱 등 다양해지면서 이러한 클라이언트들에게 정보를 제공하는 방식을 하나로 일원화시키고 싶어졌습니다. 일원화시키는 방식 중에 대표적인 방식이 HTTP프로토콜로 API를 제공하는 것입니다. HTTP프로토콜로 제공하는 API를 REST API라고 합니다.
API란? API는 Application Programming Interface의 약자입니다. wiki를 보면 API에 대한 설명이 다음과 같이 되어 있습니다. “API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공합니다. 설명만 봐서는 어떤 뜻인지 이해하기 어렵네요. 이번엔 다음의 URL주소를 보도록 하겠습니다. 참고 바로가기 위의 URL주소를 가면 java 8의 API문서를 볼 수 있습니다. 자바 언어가 제공하는 클래스와 인터페이스에 대한 설명이 API문서입니다. 자바 프로그래밍을 위해서는 자바 언어가 제공하는 것들이 어떤 것이 있는지를 알아야 합니다. 그래야, 사용할 수 있겠죠? 절대값을 구하기 위해서는 어떻게 해야 할까요? Java API문서를 읽어보면 답을 알 수 있습니다. Math클래스의 abs()메소드를 사용하면 된다는 것을 알 수 있죠. 해당 메소드가 어떻게 내부적으로 구현되어 있는지는 문서를 봐도 알 수 없습니다. 하지만, 해당 라이브러리를 사용할 때 구현코드를 알지 못해도 인터페이스만 알면 사용할 수 있습니다. 이렇게 프로그래밍을 할 때 필요한 인터페이스를 API라고 합니다.
REST API란 말 그대로 REST형식의 API를 말합니다.
이렇게 REST API가 널리 사용되었지만, REST를 논문으로 최초 소개한 로이필딩은 대부분의 REST API라고 하는 것들이 REST API가 아니라고 말합니다.
REST는 다음과 같은 스타일을 반드시 지켜야 한다고 말합니다.
client-server
stateless
cache
uniform interface
layered system
code-on-demand (optional)
여기서 스타일이란 제약조건의 집합을 의미합니다.
즉, 위에서 언급한 내용을 잘 지켜야만 REST라고 말할 수 있다는 의미입니다.
HTTP프로토콜을 사용한다면 client-server, stateless, cache, lared system, code-on-demand 등에 대해서는 모두 쉽게 구현 가능합니다.
하지만, 문제는 uniform interface입니다.
uniform interface의 스타일
리소스가 URI로 식별되야 합니다.
리소스를 생성,수정,추가하고자 할 때 HTTP메시지에 표현을 해서 전송해야 합니다.
메시지는 스스로 설명할 수 있어야 합니다. (Self-descriptive message)
애플리케이션의 상태는 Hyperlink를 이용해 전이되야 합니다.(HATEOAS)
첫 번째와 두 번째 항목은 지키기 어렵지 않은데, 메시지가 스스로 설명할 수 있어야 하는 부분과 HATEOAS를 지원하는 것은 웹과는 다르게 API로는 쉽지가 않습니다.
응답 결과에 보통 JSON 메시지(다음 시간에 간단히 다루게 됩니다.)를 사용하게 되는데, 이 JSON메시지가 어디에 전달되는지 그리고 JSON메시지를 구성하는 것이 어떤 의미를 표현해야만 메시지 스스로 설명할 수 있다고 말할 수 있는데, 그게 쉽지 않습니다.
우리가 웹 게시판을 사용할 때, 리스트 보기를 보면, 상세보기나 글쓰기로 이동할 수 있는 링크가 있습니다.
상세보기에서는 글 수정이나 글 삭제로 갈 수 있는 링크가 있습니다.
이렇게 웹 페이지를 보면, 웹 페이지 자체에 관련된 링크가 있는것을 알 수 있는데 이를 HATEOAS라고 말합니다.
이런 HATEOAS를 API에서 제공하는 것은 쉽지 않습니다.
REST API는 쉽지 않다. 그래서, 보통은 Web API(혹은 HTTP API)를 사용한다.
REST의 uniform interface를 지원하는 것은 쉽지 않기 때문에, 많은 서비스가 REST에서 바라는 것을 모두 지원하지 않고 API를 만들게 됩니다.
REST의 모든 것을 제공하지 않으면서 REST API라고 말하는 경우도 있습니다.
REST의 모든 것을 제공하지 않고 Web API 혹은 HTTP API라고 부르는 경우가 있습니다.
우리는 2번째 방식을 따르려고 합니다.
---------------------------------------------
생각보다... 구글링해서 나온 그 어떤 문서들보다 네이버 부스트코스는 잘 설명하고 있어서 놀라웠다. 맨 처음 CS50을 저기서 접했을때는 최신화가 안되어서 수업에 필요한 핵심기능이 지원되지않아서 멈추었는데... 다시 저기에 좀 자주 들어가봐야하나 고민된다.
'일상' 카테고리의 다른 글
20240209(from20240130) (1) | 2024.02.09 |
---|---|
20240208(from20240130) (0) | 2024.02.08 |
20240206(from20240130) (2) | 2024.02.06 |
20240204(from20240130) (0) | 2024.02.04 |
20240203 (0) | 2024.02.03 |