namespace のブロックの中で mount すればよい。 version に twitter/v1 のようなパスを書いても同じ URL が得られるが、 routes を表示したときに :version にまとめられてしまってわかりづらいので明示的に namespace を切ったほうがよい。 require 'grape' module Twitter module API class V1 < Grape::API version 'v1' format :json end end end module Twitter module API class V1 < Grape::API class Users < Grape::API get '/users' do { users: 1 } end end end end end module Twitter module API c
この記事はアンテクアドベントカレンダー2022の9日目の記事です。 https://adventar.org/calendars/7821 気がつけば次の順番が回ってきましたサーバーサイドエンジニアのレイジー先生です。 サーバーサイドエンジニアのはずですが今年のアドベントカレンダーではサーバーサイドの記事を書く気がないようです。PHPよりJSのほうが好きなんですよ、ぼかぁ。 というわけで前回のjQueryの話に引き続いて今回はFetch APIの話をします。 AngularJSの話を書くといったな、あれは嘘だ Fetch API、実務で使ったことないんですけどね。 細かいことは気にせずに行ってみましょう！ ひぁうぃごー！！ そもそもAJAXとは 前回の記事でも書きましたがAJAXは「Asynchronous JavaScript And XML」の略でして、「JavaScriptからXML
JavaScriptのFetchとAjaxとの完全比較｜2024年最新版 AJAX(エイジャックス)とは、JavaScriptを使ってブラウザ上でサーバーと非同期通信(Async通信)を行う技術として、さまざまな技術に集成することができます。その一方で、FetchはJavaScriptでWeb APIと通信するためのインターフェースで、非同期通信をも実現しています。そこで、本文では、JavaScript言語でのFetchとAjaxの基本情報を紹介した上、FetchとAjaxを完全に比較していこうと思います。どちらかに使用するかにまだ迷っている方は、ぜひ本文の内容を参照してください。 AJAX(エイジャックス)とは、JavaScriptを使ってブラウザ上でサーバーと非同期通信(Async通信)を行う技術として、さまざまな技術に集成することができます。その一方で、FetchはJavaScrip
app以下にAPI用のディレクトリを作成する Rails newで作られたフォルダとは別にapp/下にapi/を用意。 自動で/apiを読み込むようにapplication.rbに2行を追加する。 module RailsSample class Application < Rails::Application # 省略 config.paths.add File.join('app', 'api'), glob: File.join('**', '*.rb'), eager_load: true config.autoload_paths += Dir[Rails.root.join('app', 'api', '**', '*.rb')] end end
はじめに Grapeは、RubyでRESTful APIを簡単に作成するためのフレームワークです。 この記事では、「Grape」と「grape-entity」を使ってAPIを簡単に作成する方法をサクッとご紹介します。 ※Grape導入のため、モデルの作成、データの作成、テスト部分は省略します。以下の記事でモデルの作成、データの作成、テストの導入部分を記述しています。参考程度に読んでみて下さい。 実行環境 M2 mac mini Rails 7.1.3 Ruby 3.2.3 Mysql 8.0 Docker 25.0.2 vscodeエディタ 環境構築が済んでいない方はこちらを参考に環境構築を行なってください。 Schemafileの導入がまだの方はこちらから設定してください。 RSpecの導入 ※こちらは導入しなくてもOKです。 Grape、corsをgemファイルに追加
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? API設計、モック、テスト、ドキュメント作成を1つのプラットフォームで はじめに APIを開発する際に自分の知っている限りではこのような開発の流れとなっています。 要件を基にAPIのリクエストやレスポンスのインターフェースを設計する 設計した内容をドキュメントに残す モックを用意して、フロントエンド側の開発者が簡単な連携テストをすぐに出来るようにする APIを実装する 内部処理のテストを行う（DBに対する操作など） 実装したAPIがリクエストに対し想定通りのレスポンスを返すかAPIそのものに対するテストを行う そして、これらのフェーズで
お知らせ 📢 本記事の内容は、下記のZenn本に統合されたため、恐れ入りますが、下記をご参照ください m(_ _)m 最後に 最後まで読んでくださり、ありがとうございました！ この記事を通して、少しでもあなたの学びに役立てば幸いです！ おまけ①：生成AIアカデミー より専門的な「生成AIエンジニア人材」を目指しませんか？ そんな方々に向けて、「生成AIアカデミー（旧：生成AIエンジニア塾）」というプログラムを始めました🎉 最終的なゴールとして、『エンタープライズ向けの生成AIシステムを構築するためのスキルを習得し、大手案件で活躍できる人材』を目標とします。 また、一人一人にしっかりと向き合って、メンタリングをできるようにするため、現在メンバーの人数制限をしております。本気度やスキルレベルの高い人から、順番にご案内しております。 ▼ 登録はこちらから ▼ おまけ②：AI Newslett
ソフトウェアを常に最新に私たちはソフトウェアを最新に保つことがいかに難しいかを知っています。 ケンオールはデータを最新に保ち整理するプロセスを自動化し、変更を自動的に取り込むことができます。 さまざまなデータに対するAPIを使用して、既存のシステムを当社のシステムにリンクします。
REST APIの設計について、ログアウトAPIのHTTPメソッドについて社内で議論があったので、メモしておきます。 ログアウトといっても連携サービス(OpenID Connectなど)からのログアウトなど、サーバサイドでのユーザ属性の変化など、データ変更を伴うものではなく、単なるセッション切り替えの話です。 結論: 方針 方針としては以下のように決めていくのがいいかと思います。 APIが存在しないべき: RESTfulならそもそもセッションのステートはサーバが持っていないはずなので、ログアウトAPI自体が存在しないべき. サーバサイドでDB変更などの処理を行っていないため、クライアントでtoken/sessionの破棄を行えば事足りるはず。 DELETE: TokenのrevokeならDELETEだろう. 名前やエンドポイントがlogoutとかでも意味的にはtoken revokeならD
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Railsで作成されたAPIのテストについてこちらを参考に必要最低限の情報をまとめました。 実際にこちらの記事で作成したAPIに対してテストを書いていきます。 何をテストする？ 適切なAPIはHTTPのレスポンスのステータスコードと実際のデータを含んだレスポンスボディを返します。 よって主にその２つをテストしていきます。 ステータスコード 通常APIによって返されるステータスコードは以下の４つに分類されます。 APIの動きによってこちらのコードと照らし合わせる事でテストします。 200: OK - リクエストは成功し、レスポンスと
2020.10.01に公開 2020.10.09に更新 Udemy 12. サーバーサイドのログイン認証 No.4 / 8 今回達成すること JWT（以下、トークン）を検証し、正しければ発行主のユーザーを返すAuthenticatorモジュールを作成します。 モジュールで作成したメソッドは、Railsコントローラーのbefore_actionで読み込みます。 これにより、ログインユーザーしかアクセスできないコントローラーアクションを作成することができます。 モジュールファイルを作成する モジュールファイルは、前回作成した「services/user_auth」ディレクトリ内に作成します。 authenticator.rbを作成しましょう。 root $ touch api/app/services/user_auth/authenticator.rb UserAuthを継承したモジュールを
2020.10.01に公開 2021.06.09に更新 Udemy 12. サーバーサイドのログイン認証 No.2 / 8 今回達成すること 今回は、ログイン認証の流れを理解し、JWTの実装に入ります。 JWTの初期設定ファイルを作成するところまでをゴールとしましょう。 ログイン認証機能の参考 ここで紹介するログイン機能は、RailsAPIでJWT認証が実装できるGem knockを参考にしています。 Knockは2016年から更新が止まっており、Rails6には対応しなくなりました。（非公式版は2020年も更新あり） そこで今回は、Knockのコードを参考に1からログイン認証を手作りします。 JWTを使ったログイン認証の流れ 今回実装するログイン認証では、以下の手順で認証が行われます。 1. クライアントからログイン情報を投げる まず初めにNuxt.jsからログインに必要な メールアドレ
解決する課題 従来のWebアプリケーションでは、認証情報をCookiesを利用して保持し、ログイン状態を保つことを実現しています。 APIではブラウザを介さないことからCookiesを使用したセッションの保持は行えないため、認証時に生成したトークンを用いて認証済み（ログイン状態）であることを表現できます。 JSON Web Tokenの利用 認証時に生成するトークンは慣例通りJSON Web Token（JWT)を利用します。 Railsでは"jwt"というGemがあるので、簡単に扱うことができます。 アプリケーションによりますが、controller/concernsに認証用モジュールを設け、そこにJWT関連の処理をまとめて記載すると扱いやすいです。 暗号化・復号化の実装 手始めに、暗号化・復号化の実装例は下記のようになります。 app/controller/concerns下に作成して
背景 以前、vue.js × Rails APIでのSPA開発に挑戦しました。その際、認証にJWTを使ったのですが、ネットの記事を参考に実装したために仕組みやコードを完全に理解できていませんでした。そのためJWTの認証について改めて記事にしてまとめたいと思いました。railsでvue,reactなどと連携させてSPA開発したい方は参考になるかと思います。 #目次 JWTについて JWTで認証をする流れ 実際のrailsコード解説 vue.jsとの連携 1. JWTについて ###■JWTとはなにか JWTとはJSON Web Tokenの略で、JSON形式で表されたトークンです。著名・暗号化によってセキュアな通信ができます。 ###■JWTの中身 JWTは下記のうようにピリオド区切りで３つの要素に分かれています。 ①のヘッダー要素は、データの型やルールを指定します。 ②のペイロード要素には
はじめに RailsでFace APIを扱う記事が少なく実装に一手間かかってしまったので、 初歩的ですが今後同じように開発する方がスムーズに実装できるようにこの記事が手助けになれば幸いです！m(_ _)m この記事に期待できること RailsでFace APIを扱うためのコードを理解できる リクエストするデータについての理解が深まる(おまけ) 前提としてREST APIについての知識があればより理解してもらえると思います。 Face APIについて 本題に入る前にFace APIとは？の説明をしておきます。 Microsoftが提供するAzure APIと呼ばれるサービスの一つです。 公式サイトはこちら Face API詳細についてはこちら 実装にあたりAPIキーを必要とするのでアカウント登録をしておく必要があります。 登録方法は沢山記事があるのでそちらを参考にしてください。 私はこの当た
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebAPI で multipart/form-data を使う