You can choose the right software and services for your business based on 1,179,300+ authentic, timely reviews from real users.
概要認証・認可リクエスト制限データ形式レスポンスグループHTTPステータス・エラーサポート・FAQAPI顧客get顧客リスト取得post顧客登録patch顧客更新del顧客削除get顧客取得顧客支社get顧客支社リスト取得post顧客支社登録patch顧客支社更新del顧客支社削除get顧客支社取得顧客担当者get顧客担当者リスト取得post顧客担当者登録patch顧客担当者更新del顧客担当者削除get顧客担当者取得案件get案件リスト取得post案件登録patch案件更新del案件削除get案件取得patch受注ステータス変更patch案件のロック案件原価get案件原価リスト取得post案件原価登録patch案件原価更新del案件原価削除get案件原価取得請求get請求リスト取得patch請求ステータス変更書類(案件)patch見積書更新get見積書取得patch見積書ロックpatch
【新機能】Amazon API Gatewayに「使用量プラン」機能が追加。キーごとにスロットリングやリクエストの制限が可能に こんにちは、せーのです。先程AWS Summit NewYorkのキーノートが終わり、新機能がドカドカ発表されました。 ELBの新しいオプションやようやく出たかKinesis Analytics、ようやく出たかIPv6など目玉機能が目白押しの中、 私の方からはAPI Gatewayの新機能をご紹介します。 API Gatewayをビジネス的に使うには API Gatewayは文字通り簡単にAPIを作ることができる画期的なサービスですが、APIを使っていざ運用を行う際にビジネスモデルとして欠かせない機能として所謂「プレミアムプラン」「有料会員プラン」というものがあります。一般会員なら途中で繋がらなくなったりする時もプレミアム会員なら繋がる、無料会員なら月に何回までア
The Stripe API is organized around REST. Our API has predictable resource-oriented URLs, accepts form-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs. You can use the Stripe API in test mode, which doesn’t affect your live data or interact with the banking networks. The API key you use to authenticate the request determines w
Delivering deploymentsUsing the Deployments REST API, you can build custom tooling that interacts with your server and a third-party app. Using the REST API to interact with checksYou can use the REST API to build GitHub Apps that run powerful checks against code changes in a repository. You can create apps that perform continuous integration, code linting, or code scanning services and provide de
Ruby on Rails Advent Calendar 2017 19日目の記事です。 RailsでAPI開発するときのJSONレスポンスの生成方法についてまとめてみました。 JSONレスポンスの生成方法について RailsのHTTPレスポンスをJSONで生成する方法は以下の2つに分類されます renderメソッドにjson引数を指定する(モデル方式) templateハンドラでレンダリングする(ビュー方式) ライブラリでいうとactive_model_serializersは1のモデル方式、jbuilderやjbは2のビュー方式になります。 モデル方式はrenderメソッドにjson引数が指定されているとActionController::Renderers#_render_with_renderer_json が呼び出され、指定したオブジェクトのto_jsonメソッドが呼び出される
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
業務委託として現在 Nota 社の Gyazo のサーバサイドの開発をお手伝いさせてもらっているのですが、その中でやっていることについて幾つか紹介したいと思い、今回は開発環境で全面的に Docker を使うようにしたという話について書こ… ここでは、Web ブラウザやその他のクライアントから HTTP を介して利用し、JSON などのデータフォーマットでクライアントアプリケーションとやり取りを行うようなエンドポイントのことを Web API と呼んでいます。 Jbuilder からの移行これまでのコードでは、JSON を生成するために Jbuilder というライブラリを使っていました。これは DSL を用いて JSON を生成するライブラリで、Rails の場合は ActionView と協調して動きます。 Jbuilder からの変更の理由は幾つかあるのですが、主要な理由を挙げると、以
背景 今年の1月に弊社のネイティブアプリ向け API を刷新し、API v2 として導入した。機能開発やリニューアルなどのタイミングで徐々に移行して行っていて、振り返ると体感で生産性が2倍くらいになっていたように思う。やったのは基本的に少しきちんと RESTful API のプロトコルを定義し、それに則る形で API を書くためのレールを敷くということだった。 RESTful API は割とこなれたテーマかなと思いつつ、意外と Rails で RESTful API を導入しようとすると、そんなにメジャーな方法があるわけではなく、一個一個自分で考えてレールを敷く必要があった。 もちろん、それができるだけの融通性があるのが Rails の良いところではあるのだけど、逆に言うとあんまり全体のデザインを考えずに作って微妙なものが出来るということもまた同時に起こりうる(今回移行するきっかけになった
こんにちは、Wantedly Visit の開発をやっている竹野(@Altech_2015)です。 今年の1月に Wantedly に当初からあるクライアント向けの API を再検討し RESTful API に移行しました。これまで曖昧だった部分を RESTful の制約を活かしていくつかレールを敷いた結果、以前の Rails API と比較して生産性が2倍以上になったと感じています。 �Wantedly Visit は一番大きなアプリケーションなので大掛かりなフレームワークを入れることは難しかったのですが、やってみると ActiveModelSerializers やいくつかの汎用モジュールを組み合わせるだけで簡単に生産性が上がったので、この記事ではそれについて紹介します。 特に、API を RESTful にすることを考えた際、リクエスト本数が増えすぎたり、関連データを一緒に取ってく
背景 最近は変化し続ける要件に対応するために、システムも柔軟であることが求められています。 そのため、部分的に変更やスケールの可能なシステムを構築し、API経由で連携するマイクロサービス的アーキテクチャが増えてきています。 そういった設計の中で問題になっていくのが、従来のモノリシックなアプリケーションではIDEやコンパイラなどで行っていた、機能間のインターフェイスをどう管理するかという部分です。 Swaggerとは? SwaggerとはRESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークです。 公式サイトでは、The World's Most Popular Framework for APIsと謳っています。 その理由は、マイクロソフト、Google、IBM、SmartBearなどを大手の企業を含む「Open
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための(レスポンスボディに載せられる)標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
新年明けましておめでとうございます。zigorouです。 今回も昨年の特集に引き続き、2016年を振り返りながら2017年のAPIに関わる技術動向などを予想していきます。 サーバーレスとフルマネージドサービスの台頭 これまではオンプレミスの環境やAmazon Elastic Compute Cloud(EC2)を代表とする仮想サーバーやECS(EC2 Container Service)など、サービスの実行環境は少なからずインフラによる運用を意識した構成にすることがほとんどでした。しかし、AWS API Gateway+AWS Lambdaの組み合わせによるFunctions as a Service(FaaS)や、Google App EngineによるPlatform as a Service(PaaS)のようなフルマネージドサービスを使ったサーバーレスアーキテクチャが、現実のプロダク
この記事は、はてなエンジニアアドベントカレンダー2016の14日目の記事です。13日は id:astj による『Perl 6 のモジュールエコシステムの話とモジュールを公開する話 (2016年12月版) - 平常運転』でした。 こんにちは。Mackerelチームでアプリケーションエンジニアをやっている id:itchyny です。 Mackerelは、同じ役割を持つホストを束ねた「ロール」、そしてロールを束ねた「サービス」というまとまりでホストを管理し、一覧性の良いグラフ画面を提供しています。 ロールあたりのホスト数、そしてサービスあたりのロール数が増えると、グラフの画面のパフォーマンスに大きく影響します。 Mackerelチームでは大規模なサービスでも快適にグラフを閲覧できるように、継続的に画面のパフォーマンスを改善してきました。 本記事では、Mackerelのフロントエンドのパフォーマ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く