개발자R의 삶

HTTP API 설계 예1) 회원 관리 시스템 - POST 기반 -> 서버가 리소스를 관리함 -> Collection -> 실무는 대부분 POST기반 관리함 예2) 파일 관리 시스템 - PUT 기반 파일 목록 /files -> GET 파일 조회 /files/{filename} -> GET 파일 등록 /files/{filename} -> PUT 파일 삭제 /files/{filename} -> DELETE -> 클라이언트가 리소스를 알고있고 관리함 -> Store 예3) 리소스만으로 설계할 수 없는 경우 (실무 대부분임) /order/updateStatus /order/updateDelivery -> 동사를 사용하여 하나의 리소스에서 하나의 uri로만 할 수 없는 경우 -> controller 출처 : BY..

좋은 URL의 설계란.... 우선 리소스를 식별하라! & 리소스와 행위를 분리 회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제 API를 설계한다고 가정하면... 보통은 /retrieveMember /retrieveMemberById /updateMember /deleteMember 이렇게 설계한다. 리소스(멤버)와 행위(조회, 등록, 수정, 삭제)를 분리하는 것이 좋음. HTTP 메서드의 종류 GET / POST / PUT / PATCH / DELETE - GET : 쿼리스트링으로 리소스 조회 - POST : ..거의 대부분의 많은 요청들... - PUT : 기존 리소스를 완전히 대체 (없으면 생성). POST의 차이 : 클라이언트가 리소스의 위치를 정확하게 알고있음. - PATCH :..

HTTP : Hyper Text Transfer Protocol * 모든것을 http로 전송한다. JSON...TEXT...이미지... HTML...등등 모든것! HTTP 특징 1. 클라이언트 - 서버 구조 2. Stateless : 서버가 클라이언트의 상태를 보존하지 않는다. 따라서 중간에 서버가 어떻게 바뀌거나 추가해도 동일한 응답을 줄 수 있다. 상태가 보존된다면, 중간에 다른 서버로 요청하면 장애가 나는 것... 스케일아웃에 유리함. but... 상태를 유지해야하는 경우가 생긴다. ex) 로그인 3. 비연결성 : 서버 자원을 효율적으로 사용할 수 있음 요청하고 응답하면 연결이 끝! but... 연결을 새로 맺어야 함. css, js, 이미지 등 많은 자원을 계속 다운로드 해야함 그래서 HTTP지속..

인터넷 프로토콜 스택의 4계층 애플리케이션 계층 - HTTP, FTP (인터넷 브라우저, 기타 프로그램들) 전송 계층 - TCP, UDP 인터넷 계층 - IP 네트워크 인터페이스 계층 (LAN카드, LAN장비 등등) IP (인터넷 프로토콜) * 역할 : 지정한 주소에 패킷 단위로 데이터 전달 * IP 패킷에 들어있는 정보 : 출발지 IP, 목적지 IP, 데이터... * IP 프로토콜의 한계 1) 패킷을 받을 대상이 없거나, 서비스 불능이어도 패킷을 전송한다. 2) 비신뢰성 - 중간에 패킷이 사라진다? 여러 패킷을 보냈는데 순서대로 안온다면? 3) 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면? TCP (전송 제어 프로토콜) * TCP/IP 패킷 정보 : 출발지 PORT, 목적지 PO..