I started working on a app that will receive a "route" as json. That is the "route" itself will passed as a string to the server enclosed in a json string. I want to use a RESTful standard way of writing routes to keep things more easily debuggable later. However, as follows by example:

contact            'get all contacts
contact/:id        'get the contact by id

Ugly areas:

contact/:id/jobs            'get the contact and all jobs assigned to contact
contact/:id/jobs/filter     'get the contact and all jobs assigned to contact, 
                            'where those jobs meet a certain criteria (filter)

Now I could avoid overly verbose routes on "jobs" by having CRUD routes on "/jobs", which I will. But if I wanted limit returned "jobs" to a specific contact as in the above, is there a way to respresent that query without making up new conventions?

CodePudding user response：

As far as RESTful architecture goes, practically speaking, what you have is fine. A more strictly RESTful pattern might look like this:

/jobs?contact_id=73284
/jobs?contact_id=73284&completed=1

where 73284 is the unique ID of your contact, and completed=1 signals a filter.

It's useful to understand strict RESTful principals, but in practice impossible to be 100% compliant.

In general, the pattern is:

METHOD:/resource/represention?any=query&string=you&want=here

or

METHOD:/resource?any=query&string=you&want=here

where METHOD is GET,PUT,POST,PATCH, or DELETE. resource is a class of things (think table name), representation is a particular thing (think table row), and query parameters are like what you put in WHERE clauses in SQL.

CodePudding user response：

in my opinion, try use query, restful mostly means meaningful for me

contact/:id/jobs=>contact/:id?populate=jobs // if you want a contact with jobs, that means you still want a contact, just some additional info

contact/:id/jobs/filter=>contact/:id?populate=jobs&jobs[xx]=xx filter also means additional restrict

/jobs?contact_id=xx this shall mean you want job list, with some additional restrict

CodePudding user response：

REST doesn't care what spelling conventions you use for your resource identifiers. As long as your spellings are consistent with the production rules described by RFC 3986, you're fine.

If you have a lot of similar resources, it can be convenient to use URI Templates and variable expansion to define your family of identifiers. That allows clients to use general purpose libraries to construct your identifiers, and allows you the option of using a general purpose library to parse information out of the target URI for each request.

Beyond some purely mechanical concerns (ex: using the proper escape sequences), it really doesn't matter whether you use variable expansion in the query, or in path segments, or multiple times in each, or whatever.

There are trade offs to consider -- path segments combine well with relative resolution; application/x-www-form-urlencoded key value pairs combine well with HTML forms.

Beyond that, the machines don't care. So choose any spelling that makes things easier for some people that you care about.