REST API用于自定义参数

Question

I have an API method which supports a DELETE action:

api/jobs/:id

Once of the fields on the Job model is a reference value (not the same as the :id value).

I need to be able to expose another DELETE action that would allow a 3rd party to remove a Job by the reference field. The 3rd party would have no knowledge of the Job :id and thus need to use the reference field which they do have knowledge of.

What would be the best way to expose this? How should I handle this route?

Thanks!

Answer 1

I think your question is not about the implementation but about the style of the RESTful architecture, otherwise fill free to correct me...
So basically the comment of Buddy Yaussy is totally right. You have two options:

1) Access the entity via two different identifiers

GET/DELETE api/externaljobs/:reference

and

GET/DELETE api/jobs/:id

In a RESTful API every entity must have at least one identifier to be addressable, so having two is no problem at all.

2) Let the external client search for the right job

Depending on the technical and business restrictions you have, you could dictate that the external client has to search for the right job before he is able to delete it.

this could work via

GET api/jobs?reference=1337

get the result:

<job>
    [...]
    <id>1234</id>
</job>

and with the result of that call

DELETE api/jobs/1234

(you could also just allow DELETE on job collections, so the external client would be able to call DELETE api/jobs?reference=1337 and would not have two send two calls)

---

I personally like the second approach much more, because it looks much cleaner because everything you want is possible with basic HTTP methods and you still have just one representation of the job entity, but both of them are acceptable in a RESTful API and depend on "REST design taste" style I think.

Here are three other SO question to look into:
RESTful API behavior for entitys with two independent primary keys
REST API DESIGN - Getting a resource through REST with different parameters but same url pattern
Different RESTful representations of the same resource