CODEWITHSUNDEEP
urlrest
iwein
iwein

Reputation: 26161

What is a good way to represent a vector in a RESTful url

For a game I'm building I want to PUT tokens to a certain location on the board. The locations on the board are represented by 2D vectors, but now I'm scratching my head over the trivial problem of representing these vectors in the url.

I can think of several schemes, none of which are particularly pleasing:

  1. /point/{x}/{y} ex. /point/10/3
  2. /point/{y}/{x} ex. /point/3/10
  3. /point/({x},{y}) ex. /point/(10,3)

The problem with the first two is that it is rather arbitrary which part of the vector comes first. The third one seems risky; I can imagine that's going to be funny to debug because some user agents might encode the '(', ')' or ',' characters, although I expect my server side framework to be tolerant to that.

Have you tried something similar? Am I missing an obviously superior option?

Upvotes: 0

Views: 281

Answers (1)

Nicholas Shanks
Nicholas Shanks

Reputation: 10981

There is nothing at all unRESTful about the three examples you give:

  1. /point/{x}/{y} ex. /point/10/3
  2. /point/{y}/{x} ex. /point/3/10
  3. /point/({x},{y}) ex. /point/(10,3)

However, I would not try to represent every square on the board with it's own URI. Would clients want to GET any square individually, or only GET the whole board? If this were, for example, Checkers, it would require 64 round-trips to the server to get the status of every board square. Very inefficient! Using a single URI for the whole board means the state of each square has to be a property:

PATCH /board
{ "x": "10", "y": "3", "token": "black", .. [other params] .. }

or

PATCH /board
{ "10,3": "black", .. [other params] .. }

Don't forget, you can always POST if you can't PATCH the board.

You must define which comes first (x or y) in your API documentation. Please don't define y as being first :-)

Upvotes: 1

Related Questions