Created
May 9, 2012 18:42
-
-
Save andreineculau/2647886 to your computer and use it in GitHub Desktop.
REST: filtering
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| If you have | |
| /cars | |
| /cars/{carId} | |
| /individuals | |
| /individuals/{individualId} | |
| and then | |
| /individuals/andrei | |
| needs to link to my cars, which would be /cars?individual=andrei | |
| (( side-tracking here: maybe http://api.garage.com/cars?individual=http://api.garage.com/individuals/andrei seems better since the URIs are the IDs ? wdyt? )) | |
| Question is, would you have a link like | |
| #1 {rel:'owned-cars', href:'/cars?individual=andrei'} | |
| #2 {rel:'owned-cars' href:'/cars'} | |
| #3 {rel:'cars' href:'/cars'} | |
| Say that both cars and owned-cars support more filtering like "boughtAfter=YYYY-MM-DD", then what is the purpose of "hardcoding" individual=andrei, if the client has knowledge about the relationship's query parameters? | |
| I vote for #3, just because in this situation the rel owned-cars is not much different than "cars that relate to this individual". | |
| What's your take? | |
| PS: Per mentioned that the query parameters would be specified by the resource, but the client doesn't care about that. It only has media-types and rels, among which rel is the only one left to specify those. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you consider the first option I gave, with current-car and edit-current-car,
when you do a POST to edit the current car, a new car ID will be created, which means that "andrei" will link to car "456" now, so the API client also needs to do a GET on "andrei", to update its links.
Am I going nuts here?