RESTful APIのURI設計(エンドポイント設計) - Qiita
RESTful APIのリソース設計で述べた通り、何をリソースとするかを決めたらそのリソースを識別するURIを検討する必要がある。 エンドポイントとは何か エンドポイントとはAPIにアクセスするためのURIのこと。例えば、QiitaのAPIで自分の情報を取得する時のエンドポイントは以下となる。 http://qiita.com/api/v2/users/nagaokakenichi 似たような言葉に「エントリポイント」というものがある。エントリポイントとはプログラムやサブルーチンの実行を開始する場所のこと。 Qiita視点で考えると、 http://qiita.com/api/v2/users/nagaokakenichi を参照されることでプログラムが開始されるので、Qiitaからすると上記URIはエントリポイントとなる。 つまり、エンドポイントはAPIにアクセスする側からの、エントリポ
Spring Boot + Doma2で2WaySQLを使うまで - Qiita
背景 ここ最近、データアクセスはS2JDBC(2WaySQL)で開発をしていたということもあり、Spring Data JPAのようにクラスファイルの中に文字列として"select column1,column2 from table・・・"みたいな書き方に違和感を覚えていました。そんな時にDoma2の存在を知る機会があったので、ちょっとやってみようかなと思い試してみました。 ちなみに、今の現場ではSpring Boot + MyBatisでやっていますが、 パッと見た感じxmlでマッピング書くのがめんどくさそう xmlがjavaクラスへの依存を持ってしまっている(resultMapとか)、etc javaとSQLを分離したい そもそもあまり詳しくない ってのもあり、やっぱ慣れてる2WaySQLだなーって思っています。 ※他のO/Rマッパーをもう少し理解すれば考え方は変わってくるかもしれま
『システム設計の謎を解く』を読んだまとめ - Qiita
『システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意』を読んだのでまとめ(2014年頃に読み終わってたけどまとめるのを忘れていた)。抜粋になるが、これは良書の部類に入ると思うので設計について深く知りたい人は読んでみる価値があると思う。 設計が抱える2つの謎 ・設計という分野は範囲が広いゆえに「設計」という言葉の意味がバラバラという謎。 ・人、プロジェクト、組織によって設計の範囲が異なり曖昧という謎。 この謎を解決するために、設計という言葉に明確な定義をすることが重要。 工程の設計とシステム構成要素の設計 混乱を招いている一番のポイントは、システムライフサイクルの工程の「設計」とシステム構成要素の「設計」が横並びになっている点である(概念設計、基本設計、運用設計、画面設計、DB設計、プログラム設計、基本設計、インターフェース設計、アーキテクチャ設計、機能設計、詳細設計、
Spring BootでNo qualifying bean of typeが出た時の原因と対応 - Qiita
初歩的な内容になりますが、Spring Bootを使って開発していると「No qualifying bean of type・・・・」ってエラーを見かけることがあります。だいたいログの内容はこんな感じです。 Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.example.domain.repository.CustomerRepository] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {} インスタンスが見つ
Springで例外ハンドリング - Qiita
Springでは、Controller個別で例外をハンドリングする方法と、Controllerを横断して例外をハンドリングする方法の2通りのハンドリング方法が存在する。ここでは、RestControllerでのハンドリングを例にしてやってみる。 Controller個別で例外をハンドリングする Controller個別で例外をハンドリングする場合、Controllerクラス内にハンドリング用のメソッドを作成する。このメソッドには@ExceptionHandlerアノテーションを付与する。そうすることでそのControllerクラス内で発生した例外に対する設定を行うことができる。 @RestController @RequestMapping("api/customers") public class CustomerRestController { @Autowired CustomerS
テストコードのないプロジェクトにテストコードを導入した話 - Qiita
背景 現在私が参画しているプロジェクトは、プロダクトコードに対するテストコードがありません。 ※正確に言うと、ものによってはあるけど全体に対する割合で言うと0.5～1割程度だったので、ほぼないと言える状態。 そのため、 デッドコードが存在するプロダクトコード(品質) 責務が曖昧で長すぎるメソッド(品質) そもそもどこからも使われていないクラスの存在(品質) デグレ(品質) 保守対応(リファクタリング、業務影響のない軽微なバグの改修)の際のリグレッションテスト工数増大(コスト) テストコードを書かない文化 といったように様々な角度からの負がありました(挙げようと思えばもっとあるかも)。 目的 上記背景にある負を少しでも解消することを目的にテストコード導入推進を行います。 前提 言語：java テスティングFW：JUnit(色々検討した結果これに決定) CI：リリースブランチへマージのタイミン
SpringでAOP - Qiita
Seasar2でAOPは散々使ってきたが、Springではまだ使ったことなかったので、どんな感じになるのか簡易なコマンドラインアプリケーションで試してみた。今更感があるのでAOPとは？の説明はここでは省略。Spring AOPはXMLで設定を記述する方法もあるが、今回はアノテーションベース + Spring Bootで試してみた。 用語の整理 とはいえまず最初に用語の整理をしてみる。正直AOPでよく聞く用語は公式を直訳すると結構分かりづらく、あまり直観的ではないので語弊を恐れず簡潔に定義したい。 Aspect(アスペクト) 複数のクラスにまたがる関心事をモジュール化したもの(まとめたもの)。 JoinPoint(ジョインポイント) Advice(下記参照)を挿入する場所。場所といってもソースの特定の位置というわけではなく、メソッド(やコンストラクタ)の実行前、メソッド(やコンストラクタ)の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Thymeleafチートシート - Qiita