I’m working on a site that has quite a few pages that fall outside my limited understanding of RESTful design, which is essentially:
Create, Read, Update, Delete, Show, List
Here’s the question: what is a good system for labeling actions/routes when a page doesn’t neatly fall into CRUD/show/list? Some of my pages have info about multiple tables at once. I am building a site that gives some customers a ‘home base’ after they log on. It does NOT give them any information about themselves so it shouldn’t be, for example, /customers/show/1. It does have information about companies, but there are other pages on the site that do that differently. What do you do when you have these situations? This ‘home-base’ is shown to customers and it mainly has info about companies (but not uniquely so).
Second case: I have a table called ‘Matchings’ in between customers and companies. These matchings are accessed in completely different ways on different parts of the site (different layouts, different CSS sheets, different types of users accessing them, etc. They can’t ALL be matchings/show. What’s the best way to label the others?
Thanks very much. =)
I’m certainly no expert, but if you rethink your resources and think of them more strictly as ‘nouns’ or at least lists of data, it might be easier to fit any desired action into GET, POST, PUT, and DELETE. For example, you have a
/customers/resource could presumable have a/customers/{username}/resource for each customer. Maybe that gives them information about themselves. You could have/homebases/{username}/or/customers/{username}/homebase/as your homebase resources. Presumably, you’d access that homebase resource mainly through GET, and POST if there’s anything there to update (which I wouldn’t expect on a home-base or dashboard since it’s an aggregate resource).For ‘matchings’ you could use something like
/matchings/{customer},{company}/(yes, commas and semicolons are allowed. Commas usually mean the two parts are order-dependent and semicolon means order-independent, though there’s no rules about it). From that resource, you can have GET to read, show, and list whatever data you need (including optional query parameters passed as the body of the GET request), POST to update, PUT to create, and DELETE to delete. Using the parameters passed in GET, you could also request different views of the same data. Of course, you can have sub-resources of that matching like/matchings/{customer},{company}/invoices/{invoice#}/.I liked the book “RESTful Web Services” (2007 O’Reilly), by the way.
I hope that makes some sense and is helpful. =)