http api design
以下なドキュメントを発見しておりまして。 HTTP API Design Guide なんとなくメモをとってみました。 Contents として以下が列挙されています。 適切なステイタスコードを戻しなさい 戻すことができる全てのリソースを戻しなさい リクエストボディに含まれるシリアライズされた JSON を受け付けなさい ID じゃなくて UUID 使った方が良いですよ 標準的なタイムスタンプを使いましょう UTC 時刻は ISO8601 フォーマットで使いましょう 一貫性のあるパスフォーマットを使いましょう 小文字とダッシュを使いましょう 外部キーのリレーションは入れ子に 利便性をはかるため non-id dereferencing をサポートしなさい エラーの場合のレスポンスボディについて ETag ヘッダを含めなさい Request-Id ヘッダを API レスポンスに含めなさい P
軽量JSONパーサー『jq』のドキュメント：『jq Manual』をざっくり日本語訳してみました | DevelopersIO
jq Manual jqで簡単JSON加工 ｜ Developers.IO jqコマンドが実は高性能すぎてビビッた話 - beatsync.net JSONを超絶に読みやすくする jq コマンド - WebAPIバリバリ使うor開発する人必須 CLIでJSONの整形をする - ( ꒪⌓꒪) ゆるよろ日記 JSON形式の情報を様々な条件や書式として成形、フィルタリングツール『jq』。上記関連エントリで私もこのツールの存在を知る事になったのですが、ツールの簡易さ・便利さに感動しながら私もちょくちょく利用させてもらっています。 そこでこのエントリでは、jq公式ページに展開されている利用ガイド・リファレンス的な位置付けの『jq Manual』を写経がてらざっくり日本語訳してみました。ざっくり訳なのでこの部分の訳おかしい・間違ってる等ありましたら御指摘頂けると幸いです。例示されているサンプルコードも
JSON on HTTPやWeb APIを各言語でどうやって実装するのか
HTTPでアクセスして、JSONを返すようなWebサーバを書きたいとする。 どんな言語を選ぶか。どんなミドルウェアを選ぶか。どんなライブラリを選ぶか。 たとえば、TIOBE Softwareが公表している「Programming Community Index(PCI)」という指標がある。人気のあるプログラミング言語の数値化。これを見ていて思ったのは、「多すぎだよね、プログラミング言語」ということ。これらのうち、どの言語を勉強し、どの言語をプロジェクトに採用すべきなのか。 その感触を得るために、 「同じ仕様のREST serviceを複数言語で実装したらいいんじゃね？」 と思った。いくつかの言語で実装を起こしてみている。 前提条件 大規模な開発を想定する。ユーザの規模が大規模。トランザクション数が大規模。そして、開発者が大規模。 実用的かつモダンな開発を想定する。プロジェクト毎のバージョン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
