RESTful URLs for collection of objects - rest

Question

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.

Answer 1

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.

Answer 2

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(){}
}

Answer 3

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.