Google Forms APIが正式リリース。Googleフォームの作成や編集、集計などをプログラミングで制御可能に
Google Forms APIが正式リリース。Googleフォームの作成や編集、集計などをプログラミングで制御可能に アンケートやクイズなどを簡単に制作できるGoogleフォームをAPI経由で作成、編集できる「Google Forms API」が正式版となったことを、Googleが発表しました。 Introducing the new Google Forms API! Developers can now build powerful integrations on top of Forms. Here's how you can use the new Forms API and what’s in it → https://t.co/zLcaEw2ru1 What will you build for Google Workspace? pic.twitter.com/oSkPqx
日本の祝日APIをリリースしました - ケンオールブログ
アップデートのお知らせ(2022/03/15) 2022/03/15(火)にケンオールをアップデートしました。 アップデート内容は以下のとおりです。 新API: 日本の祝日API 郵便番号逆引き検索API: 品質の改善 祝日や休日のAPIについて、機能要望アンケートを募集中です！ 新API: 日本の祝日API 日本における祝日は、内閣府が毎年CSVデータを公開しています。 しかし、システムで祝日データを利用するとき、CSVをダウンロードし、それをシステムにロードするというのは意外と手間がかかります。 手動で更新する場合、手順自体を検証した上で運用ドキュメントを執筆する必要があります。 さらに、手動運用によるオペレーションミスのリスクも毎年つきまとうことになります。 自動化する場合、特別に祝日が移動するケースなどに対応できるようにしなければいけません。結局のところ手動でも更新できるようにして
Google Forms API登場。プログラミングでGoogleフォームの作成や編集が可能に
アンケートなどを簡単に制作できるGoogleフォームをAPI経由で作成、編集できる「Google Forms API」が発表されました。 The #DeveloperCommunity has more power! Thanks to the new Google Forms API, you have the ability to build powerful integrations on top of forms. Check out automation use cases https://t.co/3rwg3qr5Vg — Google Developers (@googledevs) October 12, 2021 Googleフォームは、質問項目や選択肢が並んだフォーム画面を作り、公開すると、自動的に結果がGoogle Spreadsheetに集計され、容易にグラフ化など
Binance Support Number API Documentation
Skip to Main ContentProductRapids API HubOne seamless connected experience that supports every type of developer as they build, use, and share APIs.Build APIsAPI HubAPI Hub for BusinessAPI Hub for EnterpriseEnterpriseInternal API HubPartner API HubSecurityCustomersVertical SolutionsResourcesEBooks & GuidesWhitepapers & ReportsDatasheets & One-Pagers VideosWebinarsDocsCoursesLearnBlogPrici
Twitter、APIバージョン2を発表、開発用途や目的別の新たな区分プロダクトトラック導入
「Twitter APIバージョン2」は、これまでとはまったく異なる基盤上に構築されており、開発者が開発を簡単に始められたり、開発規模を拡大したりできるよう、複数のアクセスレベルを設けている。 従来は、無料のスタンダード、有料でセルフサービス型のプレミアム、有料のカスタムAPIであるエンタープライズの3つに分かれていたが、今後はすべての開発者が同じAPIを使用するとともに、これまでの3つのレベルに代わって、開発用途や目的別の新たな区分としてプロダクトトラックを導入する。 今回、提供が開始されたプロダクトトラックは「スタンダード」で、デフォルトのプロダクトトラックとして、開発を始めたばかりの人や、趣味で何かを開発している人、何らかの目的があって勉強したり教えたりしている人を含めて、ほとんどの開発者が対象となる。将来的には、高度なレベルのアクセスの追加を計画している。 さらに近日中に、要件を満
GraphQL入門 - 使いたくなるGraphQL - Qiita
本記事は Livesense Advent Calendar 2016 - Qiita の24日目の記事になります。 公開から1年ほどたち、当初はRESTの次の潮流か！？みたいな感じになったものの、イマイチ盛り上がってる気配のないGraphQL。 ただ、気になっていた技術だったので、気にせず2016年が終わる前にざっと調べてみました。 ここ2日ほどでざっと調べたもののまとめなので、理解や解釈に誤りや言ってる意味がわからないところがあればご指摘いただければ幸いです。 TL;DR 内容をコンパクトにしきれず（Queryにばかり集中して、Mutationについては全然触れてないのに！）かなり長くなってしまいました。実際は、 GraphQL | A query language for your API のTOPページを読んで雰囲気を掴み、 The GitHub GraphQL API | Git
GraphQL | A query language for your API
The official GraphQL conference, by the GraphQL FoundationSEPTEMBER 19-21, 2023 • SAN FRANCISCO BAY AREA, CA GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve
OpenAPI Specification 3.0での変更点について | NTT Communications Developer Portal
Swaggerをベースとして策定が進んでいるOpenAPI Specification 3.0ですが、その内容がブログ記事になっていました。 大きく分けて6つの点が課題として掲げられています。 1. 構造の改善 Swaggerでは粒度が異なる状態で混在していた構造について、大きく変更されています。以下は TDC: Structural Improvements: explaining the 3.0 spec, part 2 | Open API Initiative にて紹介されていた画像です。 via TDC: Structural Improvements: explaining the 3.0 spec, part 2 | Open API Initiative definitions/parameters/responses/produces/consumesといったオブジェクト
トップダウン Swagger | PSYENCE:MEDIA
この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。 全国100万人のサーバサイドエンジニアのみなさん、こんにちは。産まれたばかりのサービスゼクシィキッチン で主にサーバサイドを担当している yewton です。最近きゅんきゅんしてますかー？ さて、昨今の新規サービス開発で避けて通れないのはWeb APIドキュメント作成ですね。今どきスマホアプリが無いサービスなんてあんまり無いでしょう、たぶん。APIドキュメントがクライアントとサーバ間の唯一のI/Fなわけですので、しっかり運用していきたいですよね。 とはいえExcelやらWordやらWikiやらに一生懸命書いていったって、メンテされずに陳腐化していくのがオチですね？このあたりは 以前もこのブログで取り上げられているので、ぜひ今一度読んでいただけるとよいと思います。 以
PUT か POST か PATCH か？ - Qiita
CRUDの操作をRESTで表現すると一対一で対応していないことに気づきます。RはGET、DはDELETEと考えておいて良さそうですが、CとUはPUT、POST、PATCHの3つの選択肢があり、APIを設計していると迷います。整理するためにまとめておきたいと思います。 下記の資料を参考にしました。 http - PUT vs POST in REST - Stack Overflow When to use PUT or POST | - The RESTful cookbook GitHub API v3 基本的な考え方 PUT: リソースの作成、リソースの置換 POST: リソースの作成 PATCH: リソースの部分置換 PUTはPOSTと違い、リソース名を指定して作成または更新をかけるメソッドです。PUT /articles/3421は新規作成かもしれませんし、更新かもしれません。PU
郵便番号データのダウンロード - zipcloud
サービス概要 本サービスは、日本郵便のWebサイトで公開されている郵便番号データを再配信するサービスです。 LZH形式ではなく、ZIP形式でダウンロード可能 ダウンロードしたらすぐに使える「加工済バージョン」も公開中 郵便番号データが更新されたらメールでお知らせ 郵便番号検索機能をWebサービスで利用可能 日本郵便のWebサイトで公開されている郵便番号データを、ZIP形式で圧縮しています。 ZIP形式に標準で対応しているOSであれば、LZHの解凍ソフトなしで郵便番号データをご利用いただけます。 ※解凍後のCSVファイルの仕様については、日本郵便のWebサイトをご確認ください。 ※差分データは、１つの圧縮ファイル中に「新規追加データ」と「廃止データ」を含んでいます。 ※公開しているデータは、「読み仮名の促音・拗音を小書きで表記するもの」になります。
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
Widebullet〜API Gateway with JSON-RPC〜 | メルカリエンジニアリング
SRE(Site Reliability Engineering)チームの@cubicdaiyaです。今年のはじめから開発しているWidebulletというシンプルなAPI Gatewayを紹介します。 WidebulletはJSON-RPCをベースにしたシンプルなAPI Gatewayです。Goで書かれています。 github.com JSON-RPCはJSONによるRPC(Remote Procedure Call)プロトコルで、リクエストやレスポンスのボディに含まれるJSONを利用してクライアント/サーバ間の通信を行います。 # リクエストボディ { "jsonrpc": "2.0", "method": "echo", "params": {"msg": "ok"}, "id": "1"} # レスポンスボディ {"jsonrpc": "2.0", "result": "ok",
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
API | HeartRails Geo API | 郵便番号／住所／緯度経度データ変換サービス
httpbin.org
艦これのチート - Togetter
Swaggerでのapi開発よもやま話
Google Maps API無償版のポリシー変更、猶予期間が10月12日で終了、地図が突然表示されなくなる可能性も 
Not Found
Swaggerで始めるモデルファーストなAPI開発
