제가 커뮤니티에 기여하게 된 계기는 복합적이지만 결정적인 트리거는 2024년 1월 27일에 진행된 제1회 게으른 개발자 컨퍼런스였습니다. 외부에 공개되지 않는 대학교 컴퓨터 동아리, 교육 학원, 사내에서의 발표 경험만 가지고 있던 제가 처음으로 공개된 행사에서 발표했던 한 순간이며, 처음으로 연사로서 자리했던 시간이었습니다. (이때 발표를 권유해 주신 ㅅㅇ님, ㅎㅈ님, ㅈㅇ님께 감사드립니다.) 발표를 준비했던 약 2달간의 시간은 나누고자 하는 인사이트를 정하고, 모호하게 알고 있었거나 정리하지 않았던 지식을 정리하고 다듬는 시간이었습니다. 처음에는 그때 당시 재직 중이던 회사에서 경험했던 GraphQL에 대한 인사이트를 제공하고자 했다가, 좀 더 근본적인 API 설계에 대한 이야기를 하고 싶었고 (자세한..
이 글의 결론만 알고 싶다면?최근 RESTful API라고 부르는 결과물들은 엄밀히 따지자면 대부분 RESTful한 API가 아닙니다.RESTful API라는 키워드를 만족하는데 매몰되기보다는 표준 HTTP API 요소를 활용해 API를 적절히 표현하고 확장하는 아이디어를 이해하는 것이 중요합니다.RESTful API가 적절하지 않은 시점과 상황을 고려하는 유연한 사고가 필요하다고 생각합니다. 이 글을 쓰게 된 배경2024년 1월 말 게으른 개발자 컨퍼런스에서 “소비자 관점의 API 설계 패턴, 사례 훑어보기” 라는 주제로 발표하며 맥락상 내용에서 제외했거나 시간 관계상 언급하지 못했던 부분을 글로 남겨보고자 합니다. 하단 참고 링크에서 발표 자료를 확인하실 수 있습니다. RESTful 설계 원칙에 ..
- Total
- Today
- Yesterday
- JVM
- rabbitmq
- 게으른개발자컨퍼런스
- Redis Key
- Thundering Herd
- mybatis
- HTTP
- Url
- URN
- Optimistic Locking
- Request Collapsing
- JDK Dynamic Proxy
- 근황
- cache stampede
- RPC
- transaction
- 한국 스프링 사용자 모임
- RESTful
- lambda
- URI
- JPA
- java
- spring AOP
- Switch
- spring
- cglib
- WiredTiger
- 커뮤니티 오거나이저
- configuration
- AMQP
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |