IBM DeveloperIBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Restful設計まとめ - ぺーぺーSEのブログ
Restfulな設計を個人的にまとめる。 あくまで個人的なまとめで個人的にどこからでも参照できるようにここに張る。 正しいとか間違ってるとかどうでもいいし、参考にするしないは個人で判断して。 基本方針 Restful APIの設計は基本的に以下。 処理の内容 HTTPメソッド URL リソースデータを全て取得する GET ~/api/resources idと一致するリソースを一件取得する GET ~/api/resources/{id} idと一致するリソースを一件更新する PUT ~/api/resources/{id} リソースを一件登録する POST ~/api/resources idと一致するリソースを一件削除する DELETE ~/api/resources/{id} リソースの利用可能なメソッドとパラメータを返す OPTIONS ~/api/resources URL中の「
RESTful Web APIs 読書会( 第三回 )に参加してきた - きのこる庭
久々の更新。しばらくRailsで趣味の開発に没頭しておりました。 というわけで 今回はRESTful Web APIs読書会(第三回)の参加報告を。 今回は主に「リソースの定義」と「HTTPリクエストの種類」と「安全性・べき等性」のお話。 ・リソースの定義 リソースというと結構個人的に定義が曖昧で、データベースのデータとかがメインになるのかなと思っていたけど、どうやらRESTにおいて URIで表現されるものは全てリソースになるらしい。 そしてリソースの状態は以下の二つによって表現されうるらしい。 ( 2013年12月1日改正、コメントより「リソースが（同じ状態で）複数の表現を持つ場合に、クライアントは望む表現をどのように指定するか、の選択肢である」といただきました。必ずしも二つではないということですね ) 1. Content negotiation( 「内容ネゴシエーション」とも。HTT
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
