0

We have a CORS REST API. It's clean. It works. It's almost perfect. But...

I'm trying to implement an endpoint with request specific parameters. This endpoint should accept POST, PUT, LINK and DELETE requests. And I'm not sure how to implement these parameters.

An example: A user wants to DELETE a model. There are two scenario's: one where the model is deleted and nothing else happens, and one where the model is deleted + a notification email is sent out.

Initially I implemented this parameter in a header called "X-NOTIFY-OWNER". This worked since it could be added to any of the 4 actions. But now we'd like to get rid of that header, since it's too specific to this single endpoint.

What whould be the best place to put this parameter? A query parameter sounds cleanest (since DELETE and LINK technically don't need a body), but query parameters should be used to filter content. A parameter in the request body would work too, and seems to be the prefered method; but it means sending a body with the DELETE and LINK actions...

Any thoughts on best practice in this case?

Improve this question
4
  • The X-NOTIFY-OWNER is a request or response header? Commented Sep 2, 2015 at 13:24
  • It's a request header Commented Sep 2, 2015 at 14:49
  • To be honest, I still like the header solution the most. The parameter is specific to the request. Does anyone know any examples of other api's that do something similar? Commented Sep 3, 2015 at 9:27
  • So if you still like it, why change? You said that querystring parameters are for content filtering, so keep using it for content filtering. Using the X- header seems nice and clean to me, I doubt you can get anything more meaningful or easier than that. IMO, it makes sense to use the custom header for notifying the app of extra tasks it needs to do. Commented Sep 3, 2015 at 9:31

3 Answers 3

Reset to default
1

I would stick to a query string, DELETE is supposed to ignore the body and only read the URL so it makes sense to use a query string here.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

You should use an URL parameter. As you stated, they should be used to filter output and an e-mail can be considered to be output.

Improve this answer

Comments

0

I would recommend setting up a new endpoint for the cleanest solution.

example.com/endpoint

example.com/endpointAndNotify

You could either:

  1. Setup the notify endpoint to extend the base endpoint and then add the notification logic to the notify action.

  2. Abstract out the shared logic from both actions, update each action to extend the base class and then add the specific notification logic to the notify action

This way both endpoints stay clean and concise and if you define a standard for this endpoint, any other endpoints that need notification logic can use the same standard.

Improve this answer

1 Comment

Our endpoints are the model names (nouns); so that would become: DELETE /meetings/{id} and DELETE /meetingsWithNotify/{id}. Doesn't look like a clean solution.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.