3 ms·

"For example, if you want to add the ability to create an article, it might be tempting to create a URI called /create_article/. This is wrong, because it confl

"For example, if you want to add the ability to create an article, it might be tempting to create a URI called /create_article/. This is wrong, because it conflates the object (the resource) and the action (creation)." So what URL do I use if I want to search articles? What if I want to approve articles? The simple CRUD perspective has fallen apart for me pretty quickly in practice- I need more than 6 verbs (adding HTTP OPTIONS and HEAD in there). I think HATEOAS is a pretty good approach, but there still seems to be a lot of noun-ification going on in RESTful apps just to stick with the style. (e.g, PUT //article/1234/approval used when disapproving an article)

carpo 16y ago
I've always thought that the URL to use when searching articles is the same you would use when retrieving a collection of articles, just with the search terms or filters included as parameters, ie, /articles?q=terms Approving articles could be as simple as posting TRUE to the "approved" attribute of an article, ie, /articles/1234/approved You just need to make sure that every resource that can be modified or retrieved has a URL.
- jamesbritt 16y ago
  Or treat search as a first-class resource.
  - RyanMcGreal 16y ago
    I wonder if it makes more sense to treat search as a first class method, i.e. issue an HTTP SEARCH request against a resource.
    - DougWebb 16y ago
      That could be done; WebDAV introduced several new methods to HTTP. The drawback is that your clients lose the ability to use standard HTTP libraries to talk to your service because you're using a non-standard set of methods. The 'Uniform' in URI and URL doesn't just apply to the resource identifiers; in a RESTful system the methods and representations both need to be uniform as well. That allows general-purpose clients to be able to interact with the service, and that was what made the web take off when earlier FTP and Gopher systems did not.
daredevildave 16y ago
To search use the search resource. Then you have, resource: "search results containing the word 'tuesday'"; url: /search?q=tuesday To approve you create a new approval resource: POST to /approval with the id of the resource to approve. This creates a new resource at /approval/1 Then you can revoke the approval by DELETE /approval/1
- DougWebb 16y ago
  A search resource generally isn't going to be a good idea in a RESTful design. What does it search? Your service will typically contain more than just one set of resources, so you'd end up either creating a separate search resource for each set or passing set identifiers of some sort as a query parameter to the search resource. The typical model is to have 'container' resources. For example, if /articles/9001 is a resource, /articles is the container. You can POST to the container to create a new resource, and you can GET the container to find out some information about it, such as the number of resources it contains and a list of them. For this part of the design I'll typically return a list of links to the first N resources in the container and a navigation link to the next N resources. That navigation link uses the same URL for the container resource, but with a query parameter that tells it which resource to start on. I'll typically also implement search/filter query parameters to allow further control over the list of resources to include in the container's representation.
ErrantX 16y ago
> search articles? GET /search?q=terms > What if I want to approve articles? POST /articles/articleID?approved=1 It's actually got potential to be very clean.

carpo 16y ago

I've always thought that the URL to use when searching articles is the same you would use when retrieving a collection of articles, just with the search terms or filters included as parameters, ie, /articles?q=terms Approving articles could be as simple as posting TRUE to the "approved" attribute of an article, ie, /articles/1234/approved You just need to make sure that every resource that can be modified or retrieved has a URL.

jamesbritt 16y ago
Or treat search as a first-class resource.
- RyanMcGreal 16y ago
  I wonder if it makes more sense to treat search as a first class method, i.e. issue an HTTP SEARCH request against a resource.
  - DougWebb 16y ago
    That could be done; WebDAV introduced several new methods to HTTP. The drawback is that your clients lose the ability to use standard HTTP libraries to talk to your service because you're using a non-standard set of methods. The 'Uniform' in URI and URL doesn't just apply to the resource identifiers; in a RESTful system the methods and representations both need to be uniform as well. That allows general-purpose clients to be able to interact with the service, and that was what made the web take off when earlier FTP and Gopher systems did not.

daredevildave 16y ago

To search use the search resource. Then you have, resource: "search results containing the word 'tuesday'"; url: /search?q=tuesday To approve you create a new approval resource: POST to /approval with the id of the resource to approve. This creates a new resource at /approval/1 Then you can revoke the approval by DELETE /approval/1

DougWebb 16y ago
A search resource generally isn't going to be a good idea in a RESTful design. What does it search? Your service will typically contain more than just one set of resources, so you'd end up either creating a separate search resource for each set or passing set identifiers of some sort as a query parameter to the search resource. The typical model is to have 'container' resources. For example, if /articles/9001 is a resource, /articles is the container. You can POST to the container to create a new resource, and you can GET the container to find out some information about it, such as the number of resources it contains and a list of them. For this part of the design I'll typically return a list of links to the first N resources in the container and a navigation link to the next N resources. That navigation link uses the same URL for the container resource, but with a query parameter that tells it which resource to start on. I'll typically also implement search/filter query parameters to allow further control over the list of resources to include in the container's representation.

ErrantX 16y ago

> search articles? GET /search?q=terms > What if I want to approve articles? POST /articles/articleID?approved=1 It's actually got potential to be very clean.