この関数を使用して、高レベルで Servant に変換する 1 つの例外セットを使用して API ハンドラーを実行できるようにしようとしていenterますが、型の一致に問題があります。

この最小限の定義セットを考えると、次のようになります。

私はこのタイプのエラーで終わります:

例外は、への呼び出しのある行から発生しenterます。参考までに、次の宣言enter:

したがって、 を呼び出すとenter runApp、型が次のようになると予想されます。

(上記でn ~ ExceptT ServantErr IOは、型の置換を説明するために使用していました)

そして実際には、私は他のコードから（私が模倣しようとしたが、どこが間違っていたのか理解していない）、次のenter runAppタイプを持っているべき/持っている必要があることを知っています：

したがって、質問は多数あります。

• 実際のタイプはenter runApp何ですか（ghciが私に与えるものではなく、より説明的な説明です）？
• その（IO ResponseReceived）制約はどこから来ていますか？
• 上記のコードを微調整して、ハンドラー全体が自然な変換を通過するようにするにはどうすればよいですか?

サーバントのチュートリアルに表示されているアプリを少し変更して、Readerモナドを aReaderTにしました。

問題は、関数を有効にできないことreaderServerです。型チェックはこの不可解なエラーで失敗します

何がうまくいかないのですか？

私は楽しみと利益のためにいくつかの CRUD ヘルパーを書いています。あなたがそうmemptyする:>なら、へ。

これは私が書きたいことです：

もちろん、それはすべてこの男に構築されています。

空のルートコンビネータはありますか?

これまでのところnext、これらのファミリのパラメーターを使用してこの問題を回避してきましたが、Servant の場合はあまり慣用的ではありません。

Servantは、API 定義からドキュメントを生成する方法を提供します。ただし、各エンドポイントの機能を (非公式に) 文書化する方法はありません。上記のリンクで使用されている例の場合、生成されたドキュメントには次のものが含まれます。

上記の例では、エンドポイントが何をするかを文書化する方法が欠けてGET /helloいます。これは、各エンドポイントの非公式な説明で API ドキュメントを補強する方法が欲しいということです。

私の推測では、これには異なるエンドポイントにタグを付けて一意に識別する必要があると思います。これは、私が知る限り、サーバントがサポートしていないものです。ただし、現在利用可能なものでこの問題を解決する方法を考えています。

私は次のタイプを持っています：

ここでは、JSON 表現のフィールドの名前をこのデータ型に適合させる必要があるためderiveJSON、メカニズムの代わりにを使用します。Generic

接頭辞は、型のレンズを生成するために必要ですが、JSON 表現では必要ありません。

今、私はのインスタンスを必要とするservant-swaggerを使用して、Swagger ドキュメントを生成しようとしています。ここでの問題は、生成されたスキーマが上記のアクセサ関数の指定された接頭辞付きの名前 ( 、、) を持つことです。代わりに、変更されたバージョン ( 、、および) が必要です。ToSchemaDevice_deviceId_deviceName_deviceDTypeidnamedtype

そのような方法で一般的な派生プロセスをカスタマイズする方法はありますか?