Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
Tags
- 선택자
- 카우치코딩
- margin
- 안쪽 여백
- border
- CSS
- connectionless
- 서버
- 바깥쪽 여백
- URL
- 협업프로젝트
- 요청 헤더
- 무상태
- HTTP
- 경계선
- Content
- 콘텐츠 영역
- HTML
- HTTP 메시지
- 6주포트폴리오
- 팀프로젝트
- 클라이언트
- 박스모델
- couchcoding
- IP
- padding
- 클라이언트와 서버 구조
- 응답 헤더
- 프로토콜
- HTTP 메시지 바디
Archives
- Today
- Total
목록리소스 (1)
정리하고 기록하며 성장하는
HTTP API 만들기
요구사항 회원 정보 관리 API 만들기 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URL 설계 URL (Uniform Resource Identifier) 회원 목록 조회 - /read-member-list 회원 조회 - /read-member-by-id 회원 등록 - /create-member 회원 수정 - /update-member 회원 삭제 - /delete-member 이렇게 설계 하는 것이 좋은 URI 설계 일까? 리소스를 식별하는 것이 좋은 URI 설계 이다 리소스 - 개념 자체를 의미한다 예) 미네랄을 캐라 -> 미네랄이 리소스이다 회원을 조회 하라 -> 회원이 리소스이다 리소스를 어떻게 식별하는것이 좋을까? 회원을 등록 , 수정 , 조회 하는 행위에 해당하는 것을 모..
HTTP/HTTP 메서드
2021. 12. 27. 22:17