0

We have to compute a schedule for a set of students and teachers in a school. The program takes a large amount of data. The time it takes to compute a schedule for a given input cannot be determined. It could take 2 seconds or 30 minutes. In some cases it might not be able to compute a schedule because of some conflicts even after 1 hour. We call this program the scheduler.

Option 1: Have a web server running. When the client makes a GET request, start the computation immediately and return the output when it's done.

Option 2: Have a web server running. When the client makes a GET request, take the input data and put it in a job queue, return a message to the client stating that the job is in a queue. A separate thread will keep checking the queue for new jobs. If the queue is empty, it will wait. If there is a job, it will start the scheduler with the input. When the scheduler returns the output, we take the data and send it to an endpoint that was specified when we received the job request.

Additional Information:

  1. The server doesn't store the output anywhere. It computes the output and sends it to the client. If the scheduler didn't have a solution for a given input, it sends an INFEASIBLE status code.

  2. The server also contains some other endpoints that provide some other functionality. The scheduler is not used in these endpoints.

  3. We have implemented both of the options right now.

Questions:

  1. We are taking a GET request for the endpoint in both the cases. We are not sure whether it should be GET or POST. What should be the correct method?

  2. Which option do you think is better? What other designs would work better for us?

Any kind of help will be appreciated! Thanks!

Improve this question
1
  • option 2 is best
    – Ewan
    Oct 13, 2021 at 13:16

1 Answer 1

Reset to default
1

Most client software will time you out, certainly if the job takes an hour. That strongly points towards #2. You might also find it convenient to save the output of jobs, so if you need the same result you don't have to wait ages again and just look up the previous results. Or if the client browser goes away in the meantime (crash? reboot? lost wifi?)

We have implemented both of the options right now.

Well then definitely go with #2. There are some niceties about what happens if it takes a really short time and you want to get the result back as quickly as possible, but it doesn't sound too critical?

GET vs POST

A good heuristic is that anything which incurs significant work and shouldn't be cached should be POST.

Improve this answer
6
  • 1
    Definitely POST. I think your heuristic should be turned into a much stronger directive. Per the RFCs, GET should be 'safe' and what the OP describes is not. Furthermore, using GET in this scenario is a security risk. An <img> link in a webpage or email could be used to cause the job to execute on page/email load.
    – JimmyJames
    Oct 13, 2021 at 14:34
  • @JimmyJames The request contains a body. The schema of that body is checked before the scheduler runs. So, this is not an issue. The schema checks are not that thorough and improvement can be made on that front. However, it will add an additional overhead with not much benefit. So, for now the superficial schema checks are fine.
    – sg7610
    Oct 13, 2021 at 14:57
  • @sg7610 Generally speaking, you can't send a body in a GET request. I mean, you 'can' support it on some server-side frameworks but a lot of client tooling and things like reverse-proxies will refuse to send one.
    – JimmyJames
    Oct 13, 2021 at 15:04
  • @JimmyJames Yes, I agree with your point. But, In this case this service is used by our backend. So, our frontend code won't be interacting with it directly.
    – sg7610
    Oct 13, 2021 at 15:17
  • @sg7610 I still see no reason to go against the norm here. You would be setting yourself or someone else up to have problems later. There's a standard pattern here: POST to a endpoint which creates a new resource and returns a URI that contains the result.
    – JimmyJames
    Oct 13, 2021 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.