How NOT to design an API
¯\_(ツ)_/¯

.

Well I'd either put a ?cancel=true after booking ID
Or
Add a status to booking info where I set status to cancel and send a put request where URL ends with booking ID

Seems like a load of fluff what could literally just be...

DELETE /booking/:reference

Can anyone explain a bit more for me with what's wrong in the image?

@nblackburn Unless the API is actually deleting the resource and making it unavailable to access from any other calls, DELETE isn't really doing what it says it does.

It seems entirely possible that you might want to be able to cancel a booking, and still store a record of what was cancelled and the reason as to why.

While not the prettiest call, I would argue that there isn't a much better solution that could be implemented.

@gitpush I dont think i have seen a POST /resourceName/:id request implemented before, so I think it would initially catch some people off guard (which any well designed API should not do).

In regards to a PUT request, I see it as being appropriate, as long as there isn't any failable additional processing that occurs when you cancel.

@CurseMeSlowly
The only thing I see as being truly horrific about this API as it is implemented is the fact you provide a micrositeId (which presumably is already part of the booking resource), and the bookingReference (which is already supplied by the url) in the request body

Let me know what you think though. I love a good discussion on API design

@theaviator I was thinking more that you are effectively deleting a booking but PATCH could be used to update it's status too.

It depends on your thinking so either is correct imo.

@theaviator ah I missed the arguments section. Just thought booking/{ref}/cancel is the API and thought that it seems alright to me to do it that way.

That's why I was a bit confused with this rant. Haha.

And yes, doesn't necessarily need to delete a cancelled booking since the info should still be available to visitors or booking site admins.

In either event POST is wrong

@JoshBent first time I saw someone -- a bookmark comment. 😂 Revert back to 0 for you 🤣 don't know why I found this funny 😬

@CurseMeSlowly thanks, I might have an idea who it was 😆

@theaviator oh no POST /resourceName/:id = failure! because ID is set by server and not client, post would be /resourceName only.
Agree with the PUT part you mentioned, though I think server should handle what happens when a booking is cancelled IMO and no the client sending another request

@theaviator I would be more than happy, if this end point response something like status=true or even some message.

There are like 15 endpoints that I am using and most of them have similar issue. Sometimes on success it is a raw text, sometimes its json

@CurseMeSlowly @nblackburn @JoshBent @gitpush
Is it only me who is seeing a problem with the response of this endpoint ?

@EAlie to be honest I don't think a response body is required as long as it uses correct http status codes.
But in case of errors of course a response body is required with it's correct http code.
And not like fucking Magento, that bitch returns status code 200 and a body that starts with: error 😒😒😒

@EAlie yeah return error properly and it should be enough as @gitpush explained. I applied this concept not only for API calls. As long as there isn't any error msg, it is all fine to continue to next action and show success message.

@gitpush @CurseMeSlowly agreed that the response body isn't required here and status code should be fine, but shouldn't that be documented ?

@EAlie true. their documentation just sucks 😬 or maybe work in progress 😋

@CurseMeSlowly Either way they are charging shit tons of money for that. around €160/month

@EAlie and globally it seems. Well that's how to become millionaire. Sell high, ship fast, fix later or never. 🙄

Who the hell are they? 160€ with that useless docs 😓