HTTPie – API testing client that flows with youIf you're in need of a great CLI tool to use with HTTP servers, RESTful APIs, and web services you're in luck. HTTPie from @jakubroztocil is the perfect solution 🤗 Part of December's #GHReleaseRadar https://httpie.org
APIに利用制限をかけるとしたらどういうやりかたがあるのか - おもしろwebサービス開発日記
この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。 APIに制限をかける方法について APIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に
住所確認サービス｜GeoTechnologies
平素は「住所確認・ジオコーディングサービス」をご愛顧いただきまして、誠にありがとうございます。 誠に勝手ながら、ユーザーサポート及び営業窓口は、下記の期間中お休みさせて頂きます｡ ■休業期間 2024年08月10日（土）～2024年08月18日（日） ※期間中にいただいたお問い合わせに関しましては、08月19日（月）以降に順次対応いたします。 休業期間中はご迷惑をおかけいたしますが、何卒ご了承くださいますようお願い申し上げます。
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
手作業でAPIキーを発行、請求書は手で書き起こし――「駅すぱあとWebサービス」が取り組んだWeb API改善施策：企業がAPIを提供する際のポイントとは - ＠IT
手作業でAPIキーを発行、請求書は手で書き起こし――「駅すぱあとWebサービス」が取り組んだWeb API改善施策：企業がAPIを提供する際のポイントとは 「Google Cloud Next '18」でヴァル研究所 ナビゲーション開発部テックリードの田辺純一氏は、「駅すぱあとWebサービス」の開発や運用を振り返り、企業がWeb APIを提供する際のポイントを紹介した。 Googleは2018年9月19、20日に「Google Cloud Next'18」を開催した。本稿では、ヴァル研究所 ナビゲーション開発部テックリードを務める田辺純一氏の講演「Web API の育て方：駅すぱあとWebサービスでのApigee適用事例」の内容を要約してお伝えする。 利用ユーザーを想定し、APIの機能は「一般化」して提供する 「駅すぱあと」は、出発地点と到着地点を指定すると、移動に最適な公共交通機関の情報
Pixelaを支える技術 - えいのうにっき
Pixelaの技術的な話（といっても高度なことは殆どしてないんだけど......）とか、あと今回の個人的な頑張りポイントである利用規約・GDPR対応といったところは、後日別エントリとしてまとめたいな〜と思っています。そのうち書くので、よろしかったらそちらも楽しみにしてやってくださいっ。 commit以外の数値でも草を生やせる、PixelaというAPIサービスを作った！ - えいのうにっき blog.a-know.me などと書いておきつつ、3週間ほど経ってしまった。ということで、今回はこの点に関して書く。あと、過大なタイトルについてはすみません。これ以外もう何も思いつかなかった。 思い当たる限りで、ざっと箇条書きにしていく。この記事に限らないことだけど、なにか間違ってることとか、もっといいやり方あるよ、というところがあれば、ぜひ教えて欲しい！ サーバーサイド GCP（Google Clou
commit以外の数値でも草を生やせる、PixelaというAPIサービスを作った！ - えいのうにっき
作りました！ pixe.la これはなに？ お好きな数値を登録、その登録された数値情報に基づいて、アレのあれっぽくグラフを作れるサービスです！ アレのあれってのは、これのコレ↓っぽいやつです！ ↑commit回数をグラフにした場合のイメージ。 ↑プロダクトのデプロイ回数をグラフにした場合のイメージ。 ↑体重の変動（前日比）をグラフにした場合のイメージ。 どうやって使うの？ Pixela は、サービスのトップページ以外は全部 Web API のみで構成されるサービスです！なので、ユーザー登録からなにから、全部 API でおこないます！ $ curl -X POST https://pixe.la/v1/users -d '{"token":"thisissecret", "username":"a-know", "agreeTermsOfService":"no", "notMinor":"
Pixela | Pixelation API Service
Record and Track your habits or effort. All by API. Pixela is the API service. With this service, you can get a GitHub like graph that expresses the degree of your daily various activities on a basis with a vivid gradation. All operations are performed by API. And, it's free. Pixela Sponsors Pixela provides almost all the features for free, but some features are only available to those who pay for
シンプルさとパフォーマンスを両立した API 設計と実装の一例 - HeartRails Tech Blog
こんにちは、エンジニアの村田です。今回はシンプルさとパフォーマンスを両立した API を作るためにはどうすればよいのかについて述べていきます。 背景 いままで API サーバーを作ってきて、シンプルな API にすればパフォーマンスが犠牲に、パフォーマンスを優先すれば実装が複雑になって保守が大変になるということを経験してきました。具体的には、 関連リソースの Entity が何重にもネストしていたり、同じリソースに一覧用、詳細用などの Entity があり実装、保守が大変 1. の問題を解消するためにシンプルな API にする 2. では N+1 の問題がありパフォーマンスが悪い 1. 2. の問題を解消するためにリソースの Entity はシンプルにしつつ、パラメーターで関連リソースを指定すると関連リソースの Entity を埋め込んで返すようにする 4. だと関連リソースの権限管理やペ
コマンドラインから LINE にメッセージを送れる LINE Notify
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに LINE Notifyの開発をしている渡辺です。開発者向けにLINE Notifyを使ってコマンドラインからメッセージを送るという方法を紹介いたします。 これまでシステム的にLINEにメッセージを送るためにはBot API TrialまたはBusiness Connectを使用する必要がありました。これらの機能はMessaging APIとしてより洗練されましたが、Messaging APIは高機能な一方で、API呼び出しのためには多少高度な実装が必要になります。 LINE Notifyではメッセージ送信に機能を絞り、極めて短いステップでLINEにメッセージを送れるAPIを用意しています。 curl を使ってメッセー
The NEXT of REST - onk.ninja
The NEXT of REST 前後リンク RESTful API のおさらい Rails での JSON API 実装まとめ スキーマファースト開発 The NEXT of REST REST で解決していない問題 REST っていうのは本当に難しくて、 開発者のお気持ちで API が異なる 指針であって仕様じゃないのが理由 POST がワイルドカードとして使われるとか クライアントとサーバ間のまだある精神的な溝 API はサーバが作るもので、クライアントは手出ししづらいという意識 REST だとクライアントごとに最適化した API を作りづらい Web とスマホで同じ API を使うときに不要なレスポンスがある 提供されている API が不十分なときにクライアント側で JOIN するハメに のような問題を抱えています。 これかを解決するために、API Query Language (
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
最近のサービス間のデータとイベントの連携について - クックパッド開発者ブログ
こんにちは。牧本 (@makimoto) です。最近はバックエンドシステムの設計をやったりしています。 今回は複数のサービスが存在するとき、その間でどのようにデータ連携を実現するかついて述べていきます。 背景と問題定義 cookpad.com は世界有数の規模の Ruby on Rails で作られたウェブアプリケーションです。 巨大な Rails アプリケーションは単純に起動やデプロイ、テストが遅いという問題以上に、自分の変更が与える影響範囲を予測するのが困難という大きな問題があります。cookpad のメインレポジトリ (cookpad_all と呼ばれる) には1つの mountable engine を共有する Rails アプリケーションは7つがあり、困難さに拍車をかけています。cookpad_all を触る開発者は新しい機能を追加する、既存の機能に手を入れる、不用な機能を消すな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2020-05-13 RailsとJSON:APIによるマイクロサービス構築事例
HTML/CSS to Image API
gRPC Streaming によるスケーラブルな常時接続型 API の構築
httpbin.org
Migration Guide to Google Photos Library API | Picasa Web Albums Data API | Google Developers
マイクロサービス指向 Rails API 開発ガイド/building rails api on microservices
Not Found
