CODEWITHSUNDEEP
rest
Mick
Mick

Reputation: 31919

RESTful URLs for collection of objects

I have an entity Temperature.

My URLs are designed as follows:

 GET     /api/temperatures/new
 GET     /api/temperatures/{id}/edit
 GET     /api/temperatures
POST     /api/temperatures
 PUT     /api/temperatures/{id}
DELETE   /api/monitoring/temperatures/{id}

I would like to create multiple temperatures (a collection of temperatures) at once - are there any conventions in terms of the urls to use?

So far, I came up with the following:

POST /api/monitoring/temperatures/collection
GET  /api/monitoring/temperatures/cnew

I thought there must be a convention for this already so would like to check with you.

Upvotes: 3

Views: 879

Answers (3)

kylieCatt
kylieCatt

Reputation: 11039

GET     /api/temperatures  # Getting all resources
POST    /api/temperatures  # Create new resource
GET     /api/temperatures/<id>  # Get a single resource
PUT     /api/temperatures/<id>  # Edit all fields
PATCH   /api/temperatures/<id>  # Edit some fields
DELETE  /api/temperatures/<id>  # Delete a resource

These are the kinds of URL's Fielding describes in his thesis on REST. You shouldn't be describing what an end point does in the URL especially when used properly the HTTP verbs provide plenty of information. Be aware the REST architectural style has more to it than JSON over HTTP. Generic connectors, decoupling of components and a stateless server are key components of a RESTful application.

Note: Most people probably wouldn't implement both PUT and PATCH. PUT will be fine but I included it for completeness.

In response to your comment, if you are referring to creating multiple resources with one POST request you don't need a new URL. Your application should be able to handle {temp: 45, date: ...} and [{temp: 45, date: ...}, {temp: 50, date: ...}] at the same endpoint.

Upvotes: 4

JamesA
JamesA

Reputation: 375

You can update multiple entries with a single post by sending in an array of temperatures instead of a single entry, 

POST     /api/temperatures  { [{...},{...}] }

but your api endpoint structure could be streamlined a little.

Ideally you want a simple consistent interface for all API resources.

I would personally simplify:

 GET     /api/temperatures/new
 GET     /api/temperatures/{id}/edit
 GET     /api/temperatures
POST     /api/temperatures
 PUT     /api/temperatures/{id}
DELETE   /api/monitoring/temperatures/{id}

to 

 GET     /api/temperatures            // Get all temperatures
POST     /api/temperatures            // Send in array of new entries to update
 GET     /api/temperatures/{id}       // Read a specific temperature
 PUT     /api/temperatures/{id}       // Update a specific temperature
DELETE   /api/temperatures/{id}       // Delete a specific temperature

This gives a consistent interface to the api for all temperature related calls that maps onto a CRUD interface.

Without context its hard to work out exactly what /api/temperatures/new is used for, but I would consider using a parameter on the call for finegraining the response.

e.g. 

/api/temperatures?age=new      // Get new temps

Which will allow you to use the common structure to add different types of criteria later on.

Upvotes: 0

Justinas Jakavonis
Justinas Jakavonis

Reputation: 8798

The HTTP method GET is not suitable for creating or editing resources - /api/temperatures/new and /api/temperatures/{id}/edit. HTTP GET is used for getting information without changing state in a server. You should use POST or PUT.

If you want to create multiple temperatures, you should use

POST /api/monitoring/temperatures

and consume JSON or XML list of objects.

Java example:

@POST
@Path("/temperatures")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response postTemperatures(Temperatures temperatures){
    // process and save
}

@XmlRootElement
public class Temperatures {

    public List<Temperature> temperatures;

    Temperatures(){}
}

Upvotes: 0

Related Questions