일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- HTTP
- 카우치코딩
- 프로토콜
- 요청 헤더
- HTML
- 클라이언트와 서버 구조
- 협업프로젝트
- 6주포트폴리오
- 응답 헤더
- HTTP 메시지 바디
- 콘텐츠 영역
- HTTP 메시지
- 박스모델
- IP
- 팀프로젝트
- 경계선
- 클라이언트
- margin
- CSS
- 바깥쪽 여백
- 선택자
- 서버
- connectionless
- padding
- URL
- couchcoding
- border
- Content
- 무상태
- 안쪽 여백
- Today
- Total
목록HTTP/HTTP 메서드 (2)
정리하고 기록하며 성장하는
HTTP 메서드 클라이언트가 서버에게 요청할 때 기대하는 행동 GET : 데이터를 달라 POST : 데이터를 줄테니까 처리를 해달라 HTTP 메서드 목적 자원(리소스)에 대해 서버가 수행해야 할 동작을 지정하기 위해 사용 HTTP 메서드 종류 GET : 리소스 조회 POST : 요청 데이터 처리 , 주로 등록에 사용 데이터를 담아서 서버에게 보내는 경우 데이터를 주면 서버가 처리해 준다 PUT : 리소스를 대체 , 해당 리소스가 없으면 새롭게 생성 PATCH : 리소스 부분 변경 예) 회원의 이름 변경 DELETE : 리소스 삭제 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더 부분만 반환 OPTIONS : 브라우저가 서버에게 지우너하는 옵션들을 미리 요청하고 허가된 ..
요구사항 회원 정보 관리 API 만들기 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URL 설계 URL (Uniform Resource Identifier) 회원 목록 조회 - /read-member-list 회원 조회 - /read-member-by-id 회원 등록 - /create-member 회원 수정 - /update-member 회원 삭제 - /delete-member 이렇게 설계 하는 것이 좋은 URI 설계 일까? 리소스를 식별하는 것이 좋은 URI 설계 이다 리소스 - 개념 자체를 의미한다 예) 미네랄을 캐라 -> 미네랄이 리소스이다 회원을 조회 하라 -> 회원이 리소스이다 리소스를 어떻게 식별하는것이 좋을까? 회원을 등록 , 수정 , 조회 하는 행위에 해당하는 것을 모..