Timeline for Best name/method for a RESTful endpoint that resumes a batch job
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 18, 2018 at 6:53 | history | tweeted | twitter.com/StackSoftEng/status/986498044974784512 | ||
| Apr 10, 2018 at 15:57 | vote | accept | nicholaswmin | ||
| Apr 9, 2018 at 21:28 | answer | added | VoiceOfUnreason | timeline score: 0 | |
| Apr 9, 2018 at 15:00 | answer | added | Jonah Benton | timeline score: 0 | |
| Apr 9, 2018 at 14:53 | answer | added | Blrfl | timeline score: 4 | |
| Apr 9, 2018 at 14:52 | comment | added | cHao | @NicholasKyriakides: And, if you continue, rickety as hell -- a user now has to care about a particular server's state, rather than a job's state. The entire point of REST is to avoid that. | |
| Apr 9, 2018 at 14:52 | answer | added | Ewan | timeline score: -1 | |
| Apr 9, 2018 at 14:47 | comment | added | Eric Stein | @NicholasKyriakides You are incorrect. REST says URLs should be considered opaque. There is no mention of URL naming conventions in the dissertation, and none in the HTTP spec. I don't disagree that it's "considered best practice", but it has nothing to do with REST at all. | |
| Apr 9, 2018 at 14:36 | comment | added | nicholaswmin | @cHao Not in my case. I want the user to decide which/when to restart. The searches are computationally expensive and slow. | |
| Apr 9, 2018 at 14:32 | comment | added | cHao | The most sensible approach is to get the client out of the business of watching to make sure the server does its job(s). :P A job that stopped due to a server outage should be restarted by the server when it restarts. | |
| Apr 9, 2018 at 14:28 | review | Close votes | |||
| Apr 18, 2018 at 3:03 | |||||
| Apr 9, 2018 at 14:24 | comment | added | nicholaswmin | @Dherik I'm starting to think this is the most sensible approach | |
| Apr 9, 2018 at 14:23 | comment | added | cHao | REST doesn't allow for a "restart" URL. Have one if you like, but have no illusions about its RESTfulness. The closest you might get is exposing a work queue and posting to it. | |
| Apr 9, 2018 at 14:23 | comment | added | Dherik | @NicholasKyriakides, verbs needs to be avoided, you are right. Per example, a POST /orders is better than POST /orders/create. But there are specific cases where the verbs are the only good way to describe what your restpoint do. | |
| Apr 9, 2018 at 14:20 | history | edited | nicholaswmin | CC BY-SA 3.0 | added 1 character in body |
| Apr 9, 2018 at 14:19 | comment | added | nicholaswmin | @EricStein AFAIK it does, in the sense that you should keep your resource URL's as the entity name and use the methods for performing operations; i.e avoiding denoting the operation using the URL. Even if not mentioned explicitly in a "spec" it's considered best practise. | |
| Apr 9, 2018 at 14:16 | comment | added | Eric Stein | REST has no naming conventions for URLs. | |
| Apr 9, 2018 at 14:14 | history | edited | nicholaswmin | CC BY-SA 3.0 | added 64 characters in body; edited title |
| Apr 9, 2018 at 14:13 | comment | added | nicholaswmin | @JamesT The word "restart" was probably misleading. What I meant was "resume", which continues the job processing from the last succesful point. Edited. | |
| Apr 9, 2018 at 14:12 | comment | added | JamesT | What's the difference between restarting the job, and creating a new, identical, job? | |
| Apr 9, 2018 at 14:10 | comment | added | nicholaswmin | Seriously, how is this opinion based? | |
| Apr 9, 2018 at 14:08 | history | asked | nicholaswmin | CC BY-SA 3.0 |