1

We are putting together an API to provide our vendors some simplistic direct access. I've built APIs before, and have always routed them as such:

{controller}/{action}/{id}

My boss, however doesn't think that's intuitive. He thinks we should route our API like this:

{controller}/{id}/{action}

His reasoning is this: "For object number 7, get it" or "For object number 15, save it." He thinks it makes more sense that way and that out vendors will understand it better that way. For me, it's about starting with the most detail then drilling down: "I'm dealing with an object, I need to save it, save it with id 15"

I'm trying to build an argument for keeping it standard, and the "Everyone else does it this way and we are just going to confuse people" argument doesn't seem to be effective. His response is, "We've never had an API before, so it will be OK for our customers to use it this way."

I would like to find some stronger arguments, backed up by white papers if I can find them, but I am coming up blank. What arguments would you use, and are there any whitepapers you could point me towards?

  • 2
    {controller}/{id}/{action} makes it more difficult to implement batch operations. With the other order, it's easy to do {controller}/{action} to apply to all ids. – Joel Cornett Jan 22 '14 at 16:56
  • why would you have save and get actions in a REST API? The id is a resource that you perform http PUT and GET on. – tom Jan 24 '14 at 12:53
7

Tell him that some actions won't have ID's and some will have two or more. It makes more sense to have them at the end, because otherwise the position of your {action} attribute will jump around, making the construction of your routing table much more difficult.

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.