1

While creating tools for an api, I've noticed the following inside the api specification:

GET /cookie-orders

returns the following structure as a 200 result:

{
 "first":true
 "last":false
 content:[
  {
   "id":0
   "customerName":test
    ...
  }
   ...
 ]
}

I find this a little contradicting as I think that a rest endpoint without path params should always have the potential of returning multiple resources. As I see it now this always returns a single resource with multiple resources inside of it.

I'm new to REST so I don't know if my view on this is correct or not.

The first and last property have been added for pagination.

2

I think that a rest endpoint without path params should always have the potential of returning multiple resources I'm new to REST so I don't know if my view on this is correct or not.

It isn't correct.

REST doesn't care about spelling, in particular it has no concern for how (or if) the origin server decomposes an identifier to find the mapping to the correct resource.

Technically speaking, each identifier in REST maps to a single resource. The representation of that single resource may describe a collection, but the resource is the conceptual mapping to the collection.

There is no REST rule that says particular URI must be collections. Some routing conventions will make those assertions. For example, Rails has strong opinions about encoding meaning into URI. However, you may notice in the example that /photos/new is an identifier without a path-param, and it returns a representation of a form, rather than a representation of a collection.

2

I don't consider your example to be a single resource. It returns an array of orders plus helpful paging information. This is typical of operations which return multiple entities.

While there is no standard for REST APIs, there are generally accepted conventions. Based on my experience, I would consider this one of them.

  • You're right I've made a mistake in the example, I've corrected it. The first and last properties were added for pagination so that It would be easy detect when a user is on the last page. The "next" button would be disabled when "last" equals true. – Viktor Baert Oct 9 '18 at 13:27
  • @ViktorBaert: Even with pagination info in the response, this is still perfectly valid for REST. Paginating a result set doesn't break REST standards. – Greg Burghardt Oct 9 '18 at 13:39
  • REST is more than a mere resource representation. It's an architectural style not an implementation detail. – Laiv Oct 10 '18 at 6:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.