api - PUT or POST when making idempotnet request for specific use-case -
i'm designing rest api web application.
my principles while designing api are:
- use client use cases perspective rather data model perspective. motivation: abstract db schema.
- each slash represent new use case/action.
lets in application have users, products, locations, product-news. use case user follows product-news location. if location empty user follows news product each location.
list of products , locations known.
what right method adding user follower of specific product-location combination?
i end following url:
/product/follow?product=<product_name>[&location=<location name>] the product , location names in query part because more flexible extend in future.
- the argument put: of course request idempotent - sending multiple times doesn't make other change sending once.
- the argument post: don't specify url, under resource set.
personally i'm closer put because use-case principle api (which consider right one) impotency rule seams corresponding one.
first identify resources. i'd that
/products/<product_name>/followers is list of users following product_name. can filter using query parameters:
/products/<product_name>/followers?location=<location_name> is list of users following product_name location_name.
a get request against such resource returns representation (json, xml, ...) of list of users.
post or put
a post request against such resource adds new user. request body of such post request contains details.
post /products/<product_name>/followers content-type: application/json { "user": "some user", "location: "some location" } the server respond:
201 created location: /products/<product_name>/followers/some%20user if client knows uri, can use put:
put /products/<product_name>/followers/some%20user content-type: application/json { "location: "some location" } the server again respond:
201 created location: /products/<product_name>/followers/some%20user summary
if client able know uri, can use put. the url can known server, use post.
Comments
Post a Comment