Kaizen Platformでフロントエンド開発をやっているlacoです。 新規アプリケーション開発において、API仕様中心の開発スタイルを検討し、実験的に取り入れました。 本記事ではその概要と効果を紹介します。 API仕様中心開発 API仕様中心開発を取り入れようと思ったきっかけは、2017年のNode学園祭でpika_shiさんが発表した「JSON Schema Centralized Design」です。 JSON Schema Centralized Design - Speaker Deck Kaizen Platformではリモートワークで開発しているメンバーが多く、非同期にコミュニケーションをすることが多いので、生産性を高めるためには互いの作業を待たずに独立して分業できるワークフローが必要でした。 バックエンドAPIの実装を待たないとフロントエンドが実装できないような依存関
This document summarizes Amazon Web Services Japan speaker Tsukagoshi Keisuke's presentation on AWS AppSync. It introduces AppSync as a fully managed GraphQL service that allows building GraphQL APIs integrated with various data sources like Amazon DynamoDB, AWS Lambda, and Elasticsearch. AppSync provides a GraphQL schema definition language to define types and queries, uses Apache Velocity Templa
はじめに # Nature Remo Cloud API (以降API) を利用することで、Nature Remoシリーズのセンサーから得られる情報を取得する、Nature Remoから赤外線を送信する、Nature Remo Eシリーズに接続したスマートメーターから得られる電力データを取得する、などのアクションを行うことができます。 APIは、HTTPクライアントがNatureのサーバへHTTPSリクエストを行うことで利用できる。レスポンスはJSON形式です。 Nature Remo クラウドがインターネットに向けて提供するAPIの詳細は API仕様 [Cloud API] を、Nature Remoデバイスがローカルネットワークに提供するローカルのAPIの詳細は API仕様 [Local API] を参照してください1。技術的な問い合わせはNature開発者コミュニティにてお問い合わせ
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
ReduxのGlobalStateでAPIのデータを保持するか否か Reduxではredux-thunkやredux-sagaを用いてaction内でAPIリクエストした結果をGlobalStateに保持するのがお約束になっていますが、そもそも action作成 ↓ reducerにcase追加 ↓ containerのmapStateToPropsで受け取る というプロセスが非常にめんどくさい。 しかもGlobalStateにAPIデータが保持されているかどうかで分岐もさせないといけない。 それならaxiosのPromiseをキャッシュしておいて、2度目以降同じaxios.getリクエストをした場合にそのキャッシュを返せばいんじゃね？ ということでaxios.getをキャッシュする仕組みを作ってみました。 注意点として、この中でキャッシュと呼んでいるものは永続的なものでなくリロードすると
Documentation Driven Contractsについて調べてみた May 15, 2017 ( May 15, 2017 更新 ) モチベーション 最近業務で、社内の他のチームに提供するAPIを開発している。 関わっている人が少なければ、みんなで近くに座って都度仕様について相談していけばいい。（感覚的には〜7人くらい？） しかし、会社全体の人数が多く、関わるチームも複数いるため（サービスのモバイルアプリ担当、Webフロント担当、バックエンド担当…など）包括的で都度更新されるドキュメントがないと開発効率が悪い。 とはいえ、API提供チームとしては、実装になるべく多くの時間を使いたい。具体的には以下の条件を満たす手法があればよい: ドキュメント作成にかける時間を短くできる 作成したドキュメントの内容が正確（最新であることが必須） 一番原始的な手法として、ドキュメントをちまちま人手
こんにちは！今年もコナン映画にいってきました、コナンでは服部派のエンジニア結城(@super_manner)です(*´ڡ`●) さて、今回はAPIをチームで開発するうえでつよーい味方になるツールを２つ使い比べた結果をご紹介しようと思います!! そもそもPawとInsomniaとは？ 双方ともREST APIクライアントです。 Paw paw.cloud Insomnia insomnia.rest APIを作成していると、POSTする必要があったり、User-AgentやRequestHeaderによる制約を受けたりで プラグイン追加が加速したりしますよね。 うっかりそのまま他のサイトを閲覧して全部がxmlで表示されたりすることもしばしば。 そんな煩わしさも、これらのクライアントを使うことで開放されるのです!! APIをメインに開発されている方にはもはや必需品になっているかもしれませんね。
GoにはWebサービスを作るためのフレームワークがそれなりの数存在している。 Awesome Go - Web Frameworks ただ、そこまでデファクトというものがあるわけではなく、他の言語と比べると少々乱立気味なのではないかな、という感想を持っている。この記事ではnet/httpを主軸に据え、取替可能な部品となるライブラリを利用してAPIサーバーを作成する方法を紹介する。 長くなりそうなので記事を分けて紹介する予定だけど、今日はアプリケーショングローバルな値をどのように保持するのが良いのかについて書く。 アプリケーショングローバルな値 APIサーバーにはそのアプリケーションにおいてグローバルな値を保持しておきたいケースが多い。例えばAPIサーバーの設定情報だったり、外部APIにアクセスするクライアントだったり、DBへのコネクションだったり、loggerだったり。そういったものを初期
The document describes analyzing log files using a Ruby gem called log-analyzer. It includes an example log analysis output table showing request counts, average response times, maximum response times and minimum response times for different HTTP methods and endpoints. It also discusses routing API versions by prefixing the controller namespace to match the request version in the URL.
（ピクシブ株式会社 Advent Calendar 2016 12日目の記事です） qiita.com こんにちは、エンジニアの id:geta6 です。普段は主にpixiv Sketchの開発などに携わっています。 さて、先日ISUCON6の本選が開催され、ISUketchというReactを使ったお絵かきサービスが話題になったかと思います。 この問題で採用されたアーキテクチャは『pixiv Sketch』のアーキテクチャを参考にしたものとなっています。 パフォーマンス等に関しましては本選の感想として良質な記事がいくつも執筆されていますのでそちらに譲るとして、今回はこのアーキテクチャの設計意図や利点について話します（2年前のリリース当初からずっとこの構成なので今さら感はありますが）。 どういうアーキテクチャか pixiv SketchのWeb版は、2つのサーバーから構成されています。 1つ
![pixiv Sketchのフロントアーキテクチャ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/ce43cabfdb7316dd8918eaaf8a93a77b70fb7094/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fc238d99d27621a6e29584c8bae22f1e41cf3e575%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fg%252Fgeta6%252F20161212%252F20161212144353.png)
ContextConsider a situation when you need to create a resource and the operation takes long time to complete. Actually, this scenario is not that uncommon: after all, REST is not about manipulation of a couple database rows in some CRUD scenario. REST is about manipulation of arbitrary resources, and a resource might require extensive computation in order to come to existence. So, you basically ha
はじめに APIの勉強のために、Web API: The Good Partsを読みました。平易な日本語で書いてあるので、読みやすかったです。 とはいえ、何度も本を読み返すのは大変なので、自分用まとめも兼ねて書こうと思った次第です。 1個1個まとめていくと結構な量があるので今回は「レスポンスデータの設計」についてまとめました。 本でいうと3章に書いてあります。 この記事も参考に Web API: The Good Partsの他のまとめ記事もここに載せておきます。 2.2: Web API: The Good Partsを読んだので「良いURI」についてまとめた 2.6: Web API: The Good Partsを読んだので「OAuthの仕組み」についてまとめた 4章: Web API: The Good Partsを読んだので「HTTPの仕様」についてまとめた 5章: Web AP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
