api-design

say we have a 'user' resource with unique constraint on 'name'. how would you design a REST API to handle a find-or-create (by name) use case? I see the following options: option 1: multiple requests client: POST /user {"name":"bob"} server: HTTP 409 //or something else client: GET /user?name=bob server: HTTP 200 //returns existing user option 2: one request, two response codes client: POST /user {"name":"bob"} server: HTTP 200 //returns existing user (in case user is actually created, return HTTP 201 instead) option 3: request errs but response data contains conflicting entity client: POST

REST API design indicates there are four resources archetypes: document, collection, store and controller. Store do not create new resources; therefore a store never generates new URIs. An example: PUT /users/12245/favorites/boston-celtics A user added Boston Celtics to his favorites list. But how that isn't creating a new resource ? and how it isnt generating a new URI? A store does not create a resource on its own. The user of the store creates endpoints / URIs. The contrast is between a Collection and a Store Collection A collection resource is a server-managed directory of resources.

I'm building an app using retrofit. Everything's working swimmingly, but I'm worried about the size of my API requests and would like to split them up using pagination. What would be the best strategy to page through the API automatically with Retrofit, so that all available data is downloaded by default? First, the pagination would need to be supported by the backend service that you're using. Second if you're looking to get an example of how this can be implemented from the client side using retrofit I would recommend you take a look at the u2020 project from @JakeWharton. The GalleryService

My question is about the advantages of nesting resources when building URLs for API purposes. Consider the following two alternatives for accessing an employee resource: /api/employees?department=1 # flat Vs. /api/departments/1/employees # nested Now consider the task of developing a general purpose library to access REST resources from an API. If all routes were flat, such a REST wrapper library would only need to know the name of the resource being accessed: store.query('employees', {department_id:1}) => /api/employees?department=1 However, if we were to support nested routes, this wrapper