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
- 선택자
- 서버
- 프로토콜
- HTTP
- 카우치코딩
- border
- HTTP 메시지 바디
- 요청 헤더
- HTML
- 클라이언트
- padding
- Content
- 클라이언트와 서버 구조
- 경계선
- couchcoding
- 6주포트폴리오
- 바깥쪽 여백
- HTTP 메시지
- 협업프로젝트
- 팀프로젝트
- margin
- connectionless
- 콘텐츠 영역
- 응답 헤더
- 무상태
- CSS
- 박스모델
- 안쪽 여백
- URL
- IP
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