プログラマーのSGKです。最近転職したばかりの新人ですが、宜しくお願いいたします。

ちなみに前職ではZend Frameworkを中心に担当しておりました。またその前の職場では今の開発メンバーと同じ職場で働いていたので、初めて入る会社でも勝手が分かる職場って良いですね！

さて、昨今WEB APIの利用や開発をする上でRESTが幅を利かせるようになってきました。REST、RESTful APIとは主に、「REST」という原則に基づいて設計された WEB用の API のことを指します。

とりわけRESTの説明でよく取り上げられる事として、HTTPメソッドをデータの入出力＝CRUDの機能にどう割り当てるのか、という内容を目にします。

ただしこれはHTTPの実装と反する仕様があるため、RESTが本当にAPIを設計する手段として最適なものなのか疑問に思っていたのでその事を書きます。

RESTはHTTPメソッドに対してCRUD機能を割り当てる

GET

データの取得。
SQLのSELECT

POST

データの追加もしくは更新。
SQLのINSERT、UPDATE
（PATCHを更新＝UPDATE、PUTを追加＝INSERTとしている場合がある）

DELETE

データの削除。
SQLのDELETE

これには以下の問題がある

• リクエストする際のGETの文字列長がサーバーで制限されている場合がある
• DELETEメソッドを制限しているサーバーがある
• INSERTした後に新規追加したレコードのIDを取得するような処理がある場合、どのメソッドに割り当てるのか不明。APIにCRUDでは無い設計をしたい場合もある。

という事で入出力の処理形態をHTTPメソッドに割り当てることに何の意味があるのか分かりません。

じゃあどうしよう？

使用するHTTPメソッドはPOSTだけに統一するのは一つの解ではないかと思います。

またURLを処理別で用意する必要は無いですし、関数名と引数をJSONでパックしてPOSTで渡せば良いです。
で、関数名のプリフィックスで機能を表すようにすれば良いのでは？ なんならHTTPメソッド風のプリフィックスを付けて設計すれば・・・などなど。

まとめ

この記事ではRESTのHTTPメソッドに機能を割り当てる点にフォーカスを当て否定しましたが、この他のRESTの原則にある、
「URLにパラメータを表現する」という点は一般的なWEBサイトのSEO技術に繋がる点があり有用ですし、
「セッションやクッキーを使用せずステートレスに処理する」という点はWEB上でデータをやりとりする上で押さえていた方が良いポイントだと気づかされます。

WEB APIを設計する方は「WEB API！そうだREST！」という固定観念を捨てて一度RESTをよく勉強してから、検討してみてはどうでしょうか？