은행에서 제공하는 서비스에 접근하기 위해 내가 어떤 창구 앞에 앉아 문서를 채워 넣는 모습을 상상해 보자. 웹이라는 기술에 은행의 비유를 적용해볼 수 있다. 은행 창구라는 API에 앉아 계좌이체라는 엔드포인트를 실행하기 위해 작성해야 하는 계좌번호가 URL이다.
은행 | 웹 기술 | 별명 |
나 | 웹 클라이언트 | |
은행 창구 | API | |
특정 업무를 위한 양식 | 엔드포인트 | 라우트(참고5) |
양식의 각 항목 | URL, HTTP 메서드, 헤더, 바디(참고3) |
엔드포인트는 특정 기능이나 리소스에 접근하기 위한 클라이언트의 접점이다. 엔드포인트가 요구하는 URL, HTTP 메서드, 필요한 헤더와 바디가 정해져 있다.
<HTTP 엔드포인트 약관>
•
어떤 URL에 접근할거에요?
•
어떤 메소드로 접근할거에요?
•
헤더에 어떤 정보를 담을거에요?
•
바디에 어떤 정보를 담을거에요?
반면 API는 서버 자원에 접근하는 규약이다(참고1:오개념, 참고2:참고1이 참고한 자료). API는 서버 자원에 접근하는 방법들을 총칭하는 반면(참고4), 엔드포인트는 특정한 작업을 위한 특정한 쿼리를 지칭한다는 경향이 있다(참고5:FastAPI 문서).
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.
from : 과거의 어떤 생각이 이 생각을 만들었는가?
1.
•
모델 서빙 개념을 공부하다 보니 이런 용어들이 쏟아져나왔다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?
1.
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는가?
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되고 이어지는가?
참고 : 레퍼런스