REST APIの設計について、ログアウトAPIのHTTPメソッドについて社内で議論があったので、メモしておきます。 ログアウトといっても連携サービス(OpenID Connectなど)からのログアウトなど、サーバサイドでのユーザ属性の変化など、データ変更を伴うものではなく、単なるセッション切り替えの話です。 結論: 方針 方針としては以下のように決めていくのがいいかと思います。 APIが存在しないべき: RESTfulならそもそもセッションのステートはサーバが持っていないはずなので、ログアウトAPI自体が存在しないべき. サーバサイドでDB変更などの処理を行っていないため、クライアントでtoken/sessionの破棄を行えば事足りるはず。 DELETE: TokenのrevokeならDELETEだろう. 名前やエンドポイントがlogoutとかでも意味的にはtoken revokeならD
JWTはtokenというキー名でCookieに保存する JWTの署名アルゴリズムはRSA256を利用する JWTのエンコードでは事前に作成したRSA暗号の秘密鍵を利用する JWTにはユーザーIDを保存する JWTの有効期限は14日とする 下準備 ユーザーの作成 認証対象のユーザーを作成します。ActiveModel::SecurePassword::ClassMethodsのドキュメントに従い、has_secure_passwordでパスワード管理されたデータを作成します。 Gemfile gem "bcrypt" ### モデルのマイグレーション $ rails g model user name email password_digest $ rails db:migrate user.rb class User < ActiveRecord::Base has_secure_pass
scaffold で User Model と Controller を作ります。 lock_version というカラムを追加すると Rails で楽観ロックを実装してくれます。便利ですね。 $ cd yourappname $ rails g scaffold User name:string \ email:string \ role:integer \ password_digest:string \ register_user:integer \ update_user:integer \ lock_version:integer \ activated_at:datetime \ deleted_at:datetime User.create!([ { name: 'admin', email: 'admin@example.com', role: 'admin', passw
はじめに 新しくAPIサーバーを建てるまでの話 新サービスを建てるにあたり考えなければいけないこと 開発を進めるにあたり 言語・フレームワーク・ミドルウェア選定 フレームワークどうするか GraphQLを採用するか、JSONのREST APIにするか サーバー構成をどうするか 構成管理（Infrastructure as a Code） ローカル開発環境はどうするのか CI環境を用意しておくことは重要 コーディング規約や各種規約はどうするのか API仕様作成時の方針について 各環境へのデプロイはどうするのか DDoSやSQLインジェクション対策はどうするのか DDoS対策 CORS, CSRF ミドルウェアの脆弱性 フェイルオーバーの仕組みをどうするか APIサーバーが1台落ちたときに利用者に影響が出ないか 接続先のDBが落ちた時に影響が出ないか サーバー（サービス）監視 ドキュメントをS
今回、サーバ・フロントの完全分業実現のため Swaggerを導入し、APIの仕様を管理、かつモックサーバとして機能させることに。 仕様を決める→モックサーバとして動作させるまでの流れメモ。 動作確認環境 流れ 前準備(brew/npmは入ってる前提) swagger形式のAPI仕様書作成 動作確認環境 Mac OS X以上 Swagger2.0 (Open APIは3.0が最新ですがswagger-codegen使用のため2.0を使用) はやく3.0対応してほしみ。。。 流れ ※色々インストールなどの前準備※ ①API仕様をSwagger形式(yaml)で記載、 ②Swagger-Codegenを使用してnode.jsのプロジェクトへ変換 ③サーバ起動 →モックサーバとしてブラウザ上での確認、 自分のプロジェクトからもレスポンス確認ができる 良いこと： * Githubでyamlファイルの
2018-05-12、OpenAPI Generator が公開されました。 https://github.com/OpenAPITools/openapi-generator OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec これは Swagger Codegen v2.4をフォークしたプロジェクトで、OpenAPIドキュメントから様々なプログラミング言語のAPIクライアントやスタブサーバーなどのソースコードを生成するツールです。まだベータ版のような状態で、“v3.0.0”として初回リリースすることを予定しています 。 私
APIの定義を書く：Excel仕様書はもういやだ RESTful APIを提供するサーバと、そのAPIを利用するクライアント（たとえばSPA）とを並行で開発しようとするとき、まずAPIを定義して、それに基づいてサーバ／クライアント双方の実装を進めようと考えるのは自然だと思う。 そうと決まれば、「API仕様書_20190110.xlsx」と題するファイルを新規作成し、シート別にリソース毎の定義を書き始め・・・てはいけない。せっかくAPIを定義したドキュメントを作成するなら、するのなら、ソースコードの自動生成などの恩恵も受けたい。受けられるはずだ。 少しググってみる。どうやらSwaggerというものを使えばいいらしい。Swaggerに興味を持ったタイミングで、ちょうど書店に平積みになっていた『WEB+DB PRESS Vol.108』の表紙が目に入った。そこには、「スキーマ駆動Web API開
こんにちは。エクセルソフトの田淵です。 先日、API ManagementツールのKONGを触ってみた | エクセルソフト ブログというエントリーを書きましたが、curl や Httpie を使用することで API を叩いていました。 REST を叩くなら Postman がおすすめだよ。と教えてもらいましたので、触ってみました。 2019/11/04 に大幅に加筆修正しました。 Postman とは The Collaboration Platform for API Development とあるように、API 開発をする際にアクセス、モック作成、テストなどを個人やプロジェクトで使うことができる API クライアント／サーバーです。（全部入りと思って大丈夫w） このエントリーでは Postman の API クライアントとしての様々な機能を紹介します。 インストール＆ユーザー登録 Po
Rails TutorialやProgateを一通り終えた人が、 実際にリリースされてるプロダクトを作るときによく利用されるTipsをまとめていきます。 まずはRoutesに関してです。 Routes ##概要 これまでは、 get 'users/index' => 'users#index' のようにHTTPメソッドを用いて定義していましたが、RESTを利用した方がもっと効率的です。 今回はRESTにまつわる実戦で使えるTipsを見ていきます。 なお、手で動かしながら結果を見る方法として、 サーバーを立ち上げて http://localhost:3000/rails/info/routes でブラウザから見るのがいいです。 rorensu2236さんの記事をすごい参考にしてます。 ありがとうございます。 HTTPメソッドの別の書き方 Progateで学んで来たような書き方の他にとりあえず
概要 最近は API Blueprint で仕様書を書くことが多かったのですが、Swagger が世界標準になるかもしれない、ということもあり、開発の効率化を進めるためにも概要をまとめてみようと思った次第です。 Swaggerとは Swagger は RESTful APIを構築するためのオープンソースのフレームワークのことです。「Open API Initiative」という団体がRESTful APIのインターフェイスの記述をするための標準フォーマットを推進していて、その標準フォーマットがSwaggerです。Swaggerには多くの便利なツールが提供されていることもあり、多くのメリットを享受できそうです。 Swagger Spec を書いておけば自動的にドキュメント生成までしてくれ、それだけではなく、ドキュメントから実際のリクエストを投げられる優れものです。 Swaggerのツール群
License: CC-BY-SA 3.0 © Zalando SE 2020 & CC-BY-SA 3.0 © kawasima 2020 Zalandoのソフトウェアアーキテクチャは、疎結合なマイクロサービスを中心としており、 それらはJSONペイロードをもつRESTful API群によって、機能が提供されています。 小さなエンジニアのチームは、自分たちでAWSアカウントにこれらのマイクロサービスを デプロイしたり運用したりしています。 私たちのAPIは、その多くが私たちのシステムが何をするのかを完全に表現しており、 それゆえに貴重なビジネス資産となっています。 Zalandoがとあるオンラインショップから価値あるファッションプラットフォームへと変貌を とげるために、私たちは新しいオープンプラットフォーム戦略の展開をはじめました。 なので、高品質で長持ちするAPIの設計は、私たちにとっ
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
