Fetch APIは「PATCH」だけ大文字と小文字の挙動が異なる
const url = "https://fetch-api-normalization.deno.dev"; await fetch(url, { method: "PATCH" }); await fetch(url, { method: "patch" }); 実行すると、次のようなエラーを得るはずです。 PATCH を小文字で書いた際のエラーの一例 さて、どのような条件でこのエラーが発生するのでしょうか？これが意図されたものなのだとしたら、 GET や POST は大文字・小文字を無視してよくて PATCH は無視できない理由がなにかあるのでしょうか？以下でその理由を探ってみましょう。 いつエラーが発生するか このエラーは、 Fetch API を利用して外部の HTTP サーバーに対してリクエストを行う時に、 PATCH と書くべきところを patch と書いていると発生します。
Hurl - Run and Test HTTP Requests
What’s Hurl? Hurl is a command line tool that runs HTTP requests defined in a simple plain text format. It can chain requests, capture values and evaluate queries on headers and body response. Hurl is very versatile: it can be used for both fetching data and testing HTTP sessions. Hurl makes it easy to work with HTML content, REST / SOAP / GraphQL APIs, or any other XML / JSON based APIs. # Get ho
サクッとAPIを叩く方法 (VS CodeでHTTPリクエストが送れちゃう拡張機能) - Qiita
概要 開発中のAPIを試したり、サードパーティのAPIをサクッと叩いてみたいといった時に皆さんどのようにしますか？ 私は、curlコマンドやPostmanをよく使っています。 ただ、もっと楽にHTTPリクエストを投げ、かつその時使用した情報を残すことができる方法を以前のチームメンバーに教えていただいたので、記事にしました。 REST Client 今回、紹介するのはVS CodeのエクステンションにあるREST Clientというものになります。 このREST ClientというのはVS Code上でHTTPリクエストを送信し、レスポンスを確認できる拡張機能となっています。 使用方法 使用方法はすごく簡単で、拡張子が「.http」か「.rest」というファイルで決められた構文に従いHTTPリクエストを記述するだけです。 下記にcrudの例を載せていきたいと思います。 また今回はREST A
Stripe | インターネット向け金融インフラ
グローバルな決済 オンライン、対面、またはプラットフォーム経由での決済を処理。 収益・財務処理の自動化 収益と財務を自動化してビジネスを成長させます。 サービスとしてのバンキング (BaaS) プラットフォームまたは製品に金融サービスを導入します。
Holidays JP API (日本の祝日API)
🎌 Holidays JP API 日本の国民の祝日の一覧を、JSON形式もしくはCSV形式で返すAPIです。 データは Google が用意している Googleカレンダーの情報から自動で生成しています。 去年・今年・来年のデータが取得可能です。 祝日一覧API (date) URL https://holidays-jp.github.io/api/v1/date.json 返却例 { "2017-01-01": "元日", "2017-01-02": "元日 振替休日", "2017-01-09": "成人の日" } 日付をキーに、祝日名が入ったオブジェクトを返します。 CSV形式 URL末尾の拡張子部分を csv にすることで、CSV形式で返します(全API共通)。 https://holidays-jp.github.io/api/v1/date.csv 返却例 2017-01
Torishima on Twitter: "まじかよ気象庁公式の天気予報APIができてるぞ、感激して大声で泣いちゃった https://t.co/2HQumqjel8"
まじかよ気象庁公式の天気予報APIができてるぞ、感激して大声で泣いちゃった https://t.co/2HQumqjel8
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にアクセスする側からの、エントリポ
5歳娘「パパ、変なAPIを作らないで？」 - Qiita
とある休日 娘（5歳）「パパ、一緒に技術ブログを始めない？」 娘「昔から私とパパがローカルに書き溜めてる技術記事が、かなり溜まってきたでしょ？」 娘「それをブログとして公開してみようよ」 ワイ「おお、それは楽しそうやな」 ワイ「どこのブログサービスを使おうかいな」 娘「せっかくなら、ブログシステムから自分たちで作ってみようよ」 娘「私はフロントエンドを担当するから」 娘「パパはRuby on Railsか何かで、APIを作ってよ」 ワイ「おお、Ruby on Railsなら昔やったことあるわ」 ワイ「RailsのAPIモードで、ブログ記事を返すエンドポイントを作ればええんやな」 娘「そうそう」 次の日 ワイ「API、できたで！」 ワイ「/api/articlesっていうエンドポイントにアクセスしてくれたら」 ワイ「ブログ記事が取得できるようにしておいたわ」 娘「さすがパパ」 娘「そういえば
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
草APIサービス Pixela を使って目薬の回数をiPhoneで記録出来るようにした - お？意外といけるやん！
ikkitang/eye-drops-name | Pixela https://t.co/lfsjzdMrfM #Pixela オーーー！できた！！— イルカ＠JPUG & 岡山swift (@ikkitang) 2020年1月6日 なぜやったか 自分は目を怪我していて、右目がほぼほぼ見えません。 4ヶ月に一回ぐらいの頻度で眼科に掛かってるんですが、都度 「今回はどれぐらいの頻度で目薬さしました？」 と聞かれ、「週2ぐらいでしかさせてないです」 とか正直に言って 女医さんにめちゃくちゃ怒られるという失敗を幾度となく繰り返しています。（ 本当は毎日 朝晩 ２回 点眼しないといけない。） ずっとどうにかしないとな、と思いつつ。良い管理方法が思いつかず 2〜3年・・・ 巷で話題の Pixela サービスを聞いて いい感じに出来そう！ と思い 確認してみることにしました、 Pixela is 何
gRPCを学んでいる - はこべにっき ♨
マイクロサービスや自作ミドルウェアのAPIをメンテナブルにしたいよねっていう文脈で、OpenAPIやGraphQL、gRPCといった技術が採用されるのを最近よく目にする。 バックエンドを実装しているWebエンジニアとしては、こういう仕組みが整備されつつあるのはありがたい。APIをシステムの外に公開しようとすると、ドキュメンテーション/バリデーション/クライアントの実装など、意外と副次的な作業が必要なので、、汎用化されたツールに頼れるのは助かる。マイクロサービスを用いたアーキテクチャを考えるにあたっても、システム間のアダプタをイメージしやすくなる。 そういう背景で、最近家ではgRPCを調べている。このあとはgRPCについて調べたことのメモや感想のコーナーになっているので、興味があったらどうぞ。 主な情報源 だいたいこのへんを眺めておくと、gRPCの基本については抑えることができる。 grpc
gRPCって何？ - Qiita
この記事は、gRPC を調べたことを走り書きしたレベルものです。実際の利用経験に基づいた情報でもなければ、しっかり時間をかけて裏付けをとった情報でもないため、誤った理解が含まれている可能性がある点にご注意ください。ツッコミや編集リクエストは歓迎します。 概要 gRPC は、RPC (Remote Procedure Call) を実現するためにGoogleが開発したプロトコルの1つです。Protocol Buffers を使ってデータをシリアライズし、高速な通信を実現できる点が特長です。 gRPCでは、IDL（インターフェース定義言語）を使ってあらかじめAPI仕様を .proto ファイルとして定義し、そこからサーバー側＆クライアント側に必要なソースコードのひな形を生成します。言語に依存しないIDLで先にインタフェースを定義することで、様々なプログラミング言語の実装を生成できるというメリッ
Google Cloud Vision API の 光学式文字認識（OCR）機能 試してみた - freee Developers Hub
こんにちは！freee で モバイルアプリ 開発を担当している RyoAbe です。 freee Developers Advent Calendar の10日目として、Google Cloud Vision API の導入 〜 OCR 機能の検証の結果についてまとめた記事になります。 Google Cloud Vision API とは？ Google Cloud Vision API とは GCP が提供するサービスの一つで、機械学習により画像から分析情報を抽出する以下のような機能を提供します。 乗り物や動物など、画像に写っているさまざまなカテゴリの物体（「ヨット」や「ライオン」、「エッフェル塔」など）を検出 アダルト コンテンツから暴力的なコンテンツまで、さまざまなタイプの不適切なコンテンツを検出 著名人やロゴ、ニュース イベントなどの時事的なエンティティを検出 光学式文字認識（OC
GitHub APIから学ぶ次世代のAPI実装方式GraphQL - Qiita
最近公開されたGitHubのAPIは、GraphQLという形式に対応しました。今後はこちらが主流になっていくようで、既存のREST APIからGraphQLへのマイグレーションガイドも提供されています。 今回は、このGraphQLについて、実際にGitHubのAPIを叩きながらその仕組みを解説していきたいと思います。 GraphQLとは 歴史 GraphQLは、Facebookの中で2012年ごろから使われ始めたそうです。その後2015年のReact.js Confで紹介されたところ話題となり、同年"technical preview"のステータスでオープンソースとして公開されました。その後仕様が詰められ、2016年9月に晴れて"preview"を脱し公式実装として公開されました。これと同じタイミングで、GitHubからGraphQLバージョンのAPIが公開されています。 このあたりの経緯
Web Budget API と Web に導入されつつある Budget と Cost の概念 | blog.jxck.io
Intro PWA の普及により、バックグラウンド処理をいかに制限するかといった課題が生まれた。 その対策として、バックグラウンド処理における Budget と Cost の概念が提案され、それを扱う Budget API の策定が進んでいる。 基本概念と現時点での API 外観について解説する。 Update 提案されて以降長いことアップデートがなかったが、 Mozilla Standard Position をリクエストしたところ、仕様が消えていたことがわかった。 https://github.com/mozilla/standards-positions/issues/73#issuecomment-373681407 元のリポジトリに Issue で現状を問い合わせたところ、結局開発者からの支持が得られず、 Obsolete されたとのこと。 blink-dev では Intent
microservicesにおけるAPI自動テストにまつわるエトセトラ
Test Engineers Meetup #2 https://test-engineers-meetup.connpass.com/event/50496/
Web APIのためのJSON Hyper-Schema - Tbpgr Blog
Web APIのためのJSON Hyper-Schemaについて 2015/08/05追記。DeNAの清水直樹さんのスライドを追加しました JSON Hyper-Schemaについて 下記を参照 JSON Schema Official 必要性 APIの運用にはAPIドキュメントが必要 APIの実装とドキュメントの差異をなくす必要がある JSON Hyper-Schemaを活用することで以下のようなメリットがある DSL等で作成したクラスを元にJSON Schemaを生成することでコードとSchemaの整合性がとれる Schemaを元にAPIドキュメントを生成することができる Schemaを元にValidationが可能になる Schemaを元にClientアプリケーションの自動生成できる スライド GMOペパボの高橋健一さん DeNAの清水直樹さん JSON Schema と API テ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - aspida/aspida: TypeScript friendly HTTP client wrapper for the browser and node.js.
質の高いAPIを作るための7つの習慣
海外・国内の便利なAPI一覧 - API LIST 100+