彰久(11)46この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。APIのURLは「これが正解」というものが無く、決め手に欠き、迷ってしまいがちだと思います。有名なサービスの例を見てもそれぞれ個性があります。いくつかの設計方針を用意してそれにはめていくことで、ある程度機械的に進めることができると思います。APIのURL設計で用いていた設計方針(のようなもの)について、いくつか書いてみます。基本形URLでリソースを表現する際は名詞の複数形を使います。APIの場合、Httpのメソッドと組み合わせて、以下のようなAPIにすることが考えられます。productの一覧取得111222は製品のIDです。APIを設計していると、もう少し複雑なものも出てきます。/articles/333444とすると、その記事が取得できるAPIになりそうですが、333444の部分を他人の記事のIDにした場合、それは取得できてよいのでしょうか。「自分の記事は取得できるが、他人の記事は権限がある場合のみ取得できるようにしたい」とするケースもあるとでしょう。/articles/333444」の方は自分の記事のみを取得するAPIとします。他人の記事を取得するAPIを以下のように別途用意します。/users/999888/articles/555666このように/users/999888の部分で対象ユーザーを明示します。(999888はユーザID、555666は記事のIDです。別のAPIにすることで、それぞれの機能も明確になり、実装もしやすいと思います。GET,POST,PUT,DELETEだけでは表現しづらいもの世の中の機能がすべてGET,POST,PUT,DELETEで表現できたらよかったのですが、これらだけだと苦しいこともあります。私が遭遇した例では「印刷する」「通知する(クライアントからサーバーに)」といったものがありました。/processes/777888/notifyのように、HttpメソッドはPOSTとし、リソースを表すURLの末尾に機能を表す動詞(この場合はnotify)をつけるようにしました。なってくるともはや何でもありな気もしてきますが、一応こういう例外措置ルールがあると、困った時救われます。複数一括削除いくつかのリソースをまとめて削除するAPIを考えます。/articles」のようにしてしまっては、/articlesという記事の集合リソース自体を削除するように解釈され、よくありません。いうわけで、これも「POST+末尾に動詞」で表現します。削除対象の記事のIDはbodyで指定します。APIのURL設計について、実体験を元にいくつか書いてみました。ここに書いたことが正解というわけではありませんし、つっこみどころも多いかと思いますが、この記事が少しでも参考になれば幸いです。APIの設計については、この本によくまとまっています。今回の記事でも参考にさせていただきました。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。今日はオフィスに用があるので、通勤ラッシュを避けて出社しました。この子は新メンバーのさめくんです。在宅勤務が推奨されているのでオフィスが閑散としており、すこしさみしそうです。本が出ていたので読んでみたところよかったので紹介させていただきます。使いたいときの注意点を書きました。新井成一64最近Sphinxつかってドキュメントを書いてるのですがなかなかイケています。臼田佳祐295ワークフロー自動化OSSのn8nをAWS環境で建てて検証してみました。非常に期待できるサービスです。Fargateの勉強をしています。使ってみたい方は参考にしてください。洋介255SnowflakeがAWSの東京リージョン上で稼働するようになりました。データを日本に置けます。芳賀健232こんにちは!猫様の忠実なるしもべ、芳賀健です。Tokyoで開催されました。カフェ店長のオカノです。クラスメソッド株式会社が運営するAWS・iOS・HTML5に関する技術情報サイトです。