일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- dict
- sanghaklee
- java
- NPM
- Coveralls
- primitive type
- ECMAScript2015
- ubuntu
- {}
- nginx
- Unit-test
- REST
- python
- Code-coverage
- AWS
- Travis CI
- PowerMock
- 개인정보수정
- ATOM
- Lodash
- 인프런
- Gitbook
- node.js
- Linux
- JaCoCo
- GIT
- RESTful
- sinopia
- javascript
- API
- Today
- Total
목록REST (2)
이상학의 개발블로그
RESTful API 설계 가이드에 질문 댓글이 달렸는데, 간단하게 답변하기보단 좀 자세히 답변해주고 싶어 글로 작성했습니다. 예제에 good, bad 가 있는데 bad 는 사용하지 말라는 건지 아니면 사용해도 되는데 안 좋은 예라고 말하는 건지 알 수가 없네요. 설계 가이드라고 나와 있는데 아직도 Rest api 가 완성된 형식이 없는 건지 아님 별도의 문법이 있어 각자의 서버에서 나름대로 사용자 정의가 가능한지요. 서버는 웹서버에서 바로 구축이 가능한지 아니면 따로 서버를 구축해야 되는지 구축하려면 어떻게 구성하는지 ㅠㅠ 아래 모든 답변은 필자의 개인적인 생각입니다. 잘못된 부분이 있으면 언제든 댓글로 지적해주세요. 1. 예제에 good, bad 가 있는데 bad 는 사용하지 말라는 건지 아니면 사용..
REST API 관점에서 바라보는 HTTP 상태 코드(HTTP status code) TOC Introduction HTTP 와 REST HTTP Status Code 2XX Success 4.1. 200 OK 4.2. 201 Created 4.3. 202 Accepted 4.4. 204 No Content 4XX Client errors 5.1. 400 Bad Request 5.2. 401 Unauthorized 5.3. 403 Forbidden 5.4. 404 Not Found 5.5. 405 Method Not Allowd 5.6. 409 Conflict 5.7. 429 Too many Requests 5XX Server errors Conclusion Introduction RESTful API ..