サービスの成長に伴うアーキテクチャの変更｜maybework
はじめにサービスが成長するにつれてどのような課題が発生し対策を実施していくのかを簡単なREST APIを題材に考えてみようと思います。 「あるある」REST API Serviceマルチテナントにてリソースの登録、検索、変更、削除を行うためのREST API Serviceを開発し、運用を開始する。 「あるある」Rest APIをOpen APIで定義1.とりあえずはじめました課題サービス開始時は利用状況やサービスの規模が読めないため、スケールの設計が難しい。 戦略とりあえず、早く安くサービスを構築することにする。 決まったことは以下の通り IaaS(GCP:Compute Engine,AWS: EC2,Azure: Virtual Machine)を利用する。 Multi Tenantモデルにてサービスを提供する。 サーバーレスサービス（FaaS）を選択する場面であるかもしれないが、今
JSONPlaceholder - Free Fake REST API
{JSON} Placeholder Free fake API for testing and prototyping. Powered by JSON Server + LowDB. Tested with XV. Serving ~2 billion requests each month. Sponsors JSONPlaceholder is supported by the following companies and Sponsors on GitHub, check them out 💖 Your company logo here Try it Run this code here, in a console or from any site: fetch('https://jsonplaceholder.typicode.com/todos/1') .then(re
そのフィールド、nullable にしますか、requiredにしますか - Qiita
プリミティブな型としては、 integer, number, string, boolean の4種類のみです。 さらに format というプロパティを指定すると、値の詳細なフォーマットを定義することができます。 int32, int64, float, double あたりは言わずもがなですね。 string に関しては byte と binary の他に、ISO 8601（RFC3339）で定義されている日付形式が表現可能です。 基本形式: 20191129T203637+0900 拡張形式: 2019-11-29T20:36:37+09:00 password はいまいちよく分かりません。 OASとして定義されているフォーマットは以上なのですが、 format には他にも自由に値を設定することができます。 email や uuid, uri, hostname, ipv4, ipv
Overview
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
RESTful API設計におけるHTTPステータスコードの指針 - Qiita
RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ
Hyphen, underscore, or camelCase as word delimiter in URIs?
I'm designing an HTTP-based API for an intranet app. I realize it's a pretty small concern in the grand scheme of things, but: should I use hyphens, underscores, or camelCase to delimit words in the URIs? Here are my initial thoughts: camelCase possible issues if the server is case-insensitive seems to have fairly widespread use in query string keys (http://api.example.com?**searchQuery**=...), bu
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
Inclusive Technology Consulting - Bocoup
Building a back-end API layer introduces a whole new layer of coordination between server and client code. While there are many aspects to this delicate dance of communication, one key ingredient to minimizing back-and-forth-confusion-about what-call-does-what, is consistently communicating about your API endpoints. This is by no means rocket science, but over time I’ve created a template that I n
Nobody understands REST or HTTP
Jul 03 2011 HI HN, PLEASE READ THIS!!! Since I’ve posted this, I’ve refined a few of my positions on things. Everyone learns and grows, and while I still stand by most of what I said, I specifically don’t agree that versioning the media type is how to properly version APIs. Hypermedia APIs should not actually use explicit versioning, but I’d rather see a version in the URI with HATEOAS than no HAT
Sinatraを使って、RESTFulなWeb-APIを作ってみたい - tackun note
このエントリはRuby AdventCalender 2011の企画です Ruby Advent Calendar の26日目の記事です。25日目はid:seiunskyさんの" おまいらもMacRubyでMacアプリ作ろう - すがブロ"でした。 みなさまクリスマスはいかがお過ごしでしたか？ 私は６ヶ月の息子と初クリスマスでほくほくです。 Ruby Advent Calenterはクリスマスが終わってもまだまだ続きますよ！ Sinatraを使って、RESTFulなWeb-APIを作ってみたい Web初心者の僕がWeb-APIを作ってみたくなったので、やってみます。 www.xxxxx.xxx/user/0001 とかにHTTP-GETメソッドでアクセスすると、0001というIDを持ったuserの情報をXMLで取得 同じURIにHTTP-PUTメソッドでXMLデータを送信すると、0000と
APIの作成に特化したRuby製フレームワーク grape を試してみた
RESTful API の作成に特化したマイクロフレームワーク grape の存在を知ったので調査してみる事にしました。API の実装 に Rails の ActionController は重厚すぎる、Sinatra は軽いけど手間がかかる。。。という中で作られたこのフレームワーク、はたしてその実力は… grape の特徴# grape の特徴は概ね以下の通りです。grape 自体が Rack アプリケーションなので Rails3 に組み込むことが出来ます。というよりは組み込んで使うのが前提のようです（勿論単体でも動きます）。 Rack アプリケーション Sinatra ライクな DSL 自動で JSON にシリアライズ（#serializable_hash または #to_json が存在すればOKみたい） grape を使ってみる# 特徴を掴んだところで、実際にインストールして使って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
#350 REST API Versioning - RailsCasts