항상 좋은영상 감사합니다. 일할때 고민된 부분들에대해서 다뤄주셔서 도움이 많이 되네요. 질문이 하나 있는데, 혹시 GET 기능인데 인자가 너무 많을 경우 body를 쓰기위해 POST로 해도 괜찮을까요? 가령 그래프 차트를 GET 해오는 API가 있을 때, 그 조건들이 10개 이상일 경우. GET으로 하기에는 너무 비대해지는것 같아서 POST로 하면 어떨까 싶거든요.
RDBMS인데 한테이블에 doc 형식 처럼 넣고 index 많이 만들고 CUD성능 그리고 특정 RDBMS의 MVCC에 따른 구조따위 버려놓고 느리다고 문제 있다고 하는... JAVA 개발을 RDBMS중에 가장 신뢰성 높은 Oracle에서 프로젝트 리드를 하고 있는데 최소한 언어적 특성 때문에 그런일을 만들었다면 그 부분이 고쳐지지... 무슨 말도 안되는 소리를 한건지 ... 정말 악몽 그 자체...
![[10분 테코톡] 무민, 테오의 RESTful API](/img/n.gif)
4:00 요즘사람들은 db공부안하는 것 같아요 15:00 header 토큰 20:01 createdAt은 나쁜 namingConvention
동사는 써야 되고, DELETE는 실제 삭제 않더라도 비즈니스 로직 레벨에서의 삭제를 의미 한다면 써야 한다고 생각함
유익한 시간이었습니다. 감사합니다.
5:52 진짜 뭔 이상한 변명인지... 자바쓰는데 저런 짓 안 합니다.
동사를 쳐박자 공감...
항상 좋은영상 감사합니다. 일할때 고민된 부분들에대해서 다뤄주셔서 도움이 많이 되네요.
질문이 하나 있는데, 혹시 GET 기능인데 인자가 너무 많을 경우 body를 쓰기위해 POST로 해도 괜찮을까요?
가령 그래프 차트를 GET 해오는 API가 있을 때, 그 조건들이 10개 이상일 경우. GET으로 하기에는 너무 비대해지는것 같아서 POST로 하면 어떨까 싶거든요.
Rest규약 위반이긴 합니다만. 모든 api가 rest를 따를 필요는 없죠
유익한 영상 감사합니다
RDBMS인데 한테이블에 doc 형식 처럼 넣고 index 많이 만들고 CUD성능 그리고 특정 RDBMS의 MVCC에 따른 구조따위 버려놓고 느리다고 문제 있다고 하는... JAVA 개발을 RDBMS중에 가장 신뢰성 높은 Oracle에서 프로젝트 리드를 하고 있는데 최소한 언어적 특성 때문에 그런일을 만들었다면 그 부분이 고쳐지지... 무슨 말도 안되는 소리를 한건지 ... 정말 악몽 그 자체...
어디 은행인지 고객들이 고생하겠네요..
Graphql에 대한 의견 영상좀용ㅋ
사용성 좋다. 캐시 안된다. 굳이 왜 벌써 사용?
감사합니다!
04:20
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
11:50 공감
오늘도 1유용😀
하이라이트 5:52 5:56
일단 GraphQL이 갓인듯..
관점 따라 다르죠. 아직 실무에서는 REST가 갑입니다