OpenAPIにおけるundefinedとnullの設計 | フューチャー技術ブログ
はじめにOpenAPI仕様に則ってREST APIの設計をする際に、値が存在しないという状態をどのように表現するかというお話です。 undefinedとはまずはじめに、ここでundefinedと言っているのは、OpenAPIの仕様において、リクエスト/レスポンスのデータ型を定義するSchema Objectのプロパティの1つであるrequiredが指定されていない状態を指します。 OpenAPIにおけるrequiredの定義を確認してみましょう。 OpenAPIの仕様を参照すると、Schema ObjectはJSON Schemaの仕様に従うと記載されています。 The Schema Object allows the definition of input and output data types. These types can be objects, but also primit
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
APIの仕様は開発フローの最初に決める 「楽楽勤怠」の開発担当がたどり着いたバックエンドとフロントエンドを仲よくさせる方法
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「SaaS新規プロダクトの技術」をテーマに、同社プロダクト「楽楽勤怠」の開発を担当する西角知佳氏が登壇し、「はじめてのフロントエンド・バックエンド分離」という内容で話をしました。 楽楽勤怠の開発体制 西角知佳氏（以下、西角）：「はじめてのフロントエンド・バックエンド分離」ということで西角がお話しいたします。よろしくお願いします。 まず簡単に自己紹介から。西角知佳と言います。2015年にラクスに新卒で入社しまして、入社以来「楽楽精算」という商材の運用保守や機能の開発を担当していました。去年（2019年）から新サービスの「楽楽勤怠」の機能開発を担当しています。 そんな楽楽勤怠ですが、まもなくのリリースに向けて鋭意開発中です。今回は、そんな楽楽勤怠の開発における話をしたいと思います。 楽楽勤怠の開発体制からですが
Web API の CSRF 対策まとめ【追記あり】 - Qiita
セキュリティ脆弱性診断などでたまに CSRF について指摘されることがあります。 今まではトークン発行して対応すれば良いんでしょ？ と思ってましたが、SPA のように非同期通信が前提の場合はどう対処するべきなんだろう、と疑問が出たりしたので、調べてみた結果をまとめてみました。 CSRFとは Cross Site Request Forgeries（クロスサイトリクエストフォージェリ）の略で、 サービス利用者の正規権限を利用して、意図しないタイミングでサービスの機能を実行させる攻撃手法のことを指します。 2005年に mixi 日記で発生した「ぼくはまちちゃん」で一躍有名になりました。 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは？ - ITmedia エンタープライズ CSRF が発生する原因 サービスの機能を実行するプログラムへのリクエストの検証が権限情報のみであった場合に発生
Laravel で GraphQL やるなら、 Lighthouse が良い - Qiita
Laravel と組み合わせて、 GraphQL サーバーを本番運用しています。 Lighthouse というライブラリを使うと、手軽に構築することができました。そのときに溜めた知見です。 結論 Laravel + GraphQL は、 Laravel の柔軟性と GraphQL の堅牢性がいい感じにマッチしている Laravel で GraphQL やるなら、 Lighthouse 良い Schema をダンプしてチームでシェアするといい感じになる GraphQL を現実世界で使う GraphQL を使う動機としては、下記があると思います。 型安全な Web API を作りたい 入出力を明確にしたい フロントとサーバー間の仕様書を、動いているコードから明確に作りたい ただ、障壁となってくるのが 既存のサービスのロジックを使いまわしたい 徐々に移行したい。三ヶ月かかります、みたいなのはきつ
一番分かりやすい OAuth の説明 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。 ※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。Authlete アカウント登録はこちら！ ※2：そして２回目の
日時のフォーマット（ISO 8601） - Qiita
ISO 8601 の中でも書き方は色々とありますが 年月日と時間 タイムゾーンに対応 年は4桁（2桁では年が確定できない） 単位は秒まで（ミリ秒も可能だが桁数が定まっていないため） という条件から利用しやすいフォーマットです。 利用実例 YouTube Data API https://developers.google.com/youtube/v3/docs/videos?hl=ja AWS (Amazon Web Services) の一部のサービス Kintone https://cybozudev.zendesk.com/hc/ja/articles/201941754-REST-API%E3%81%AE%E5%85%B1%E9%80%9A%E4%BB%95%E6%A7%98#step6
翻訳: WebAPI 設計のベストプラクティス - Qiita
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 さん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://public-apis.io/