1

I have REST API for my SPA application. My domain model has Order entity, it has Commission property which calculated on backend, it is number value

For get Order entity SPA calls this endpoint, this endpoint returns saved order

GET /api/orders/{id}

This endpoint returns basicly filled model for new Order

GET /api/orders/new

User fills other data and saves new Order by

POST /api/orders/

But user would like know value of Commission for Customer before Order saved, and it is problem, we call REST API when user changes several fields which connected with value of commission, but I do not undestand how to choouse name and method of this REST endpoint

For existed Order it is simple, this endpoint can calculate commission and returns it for SPA

GET /api/orders/{id}/commission

But what about not saved Order without Id? For calculating commission we need send many fields from Order model which is really complex and we can not use GET, simple way define such endpoint by POST

POST /api/calculateCommission

Or

POST /api/orders/commission

And send Order model JSON in this endpoint, but it is not REST way. What is good way for do it?

  • Is there (or is gonna be) more clients beside your own SPA? What's the real problem with but it is not REST way? I mean, would a non-REST API endopoint solve the problem? If yes, what's the real concern? – Laiv Oct 30 '18 at 21:37
  • Thanks for your comment. Part of this API will be avaliable for other clients, but not this endpoint, of course I can create any endpoint solved this problem,for example in RPC style. But I try create API in common style, majority of operations for SPA good described in REST style. But not such cases, common style for api make more easy supporting of api for other developers and also I can describe recommendations for other developers for changes of API. I would like to get recommendations for describe such cases in REST style, because didn't find such cases in REST recommendations. – Andrey G. Oct 31 '18 at 10:20
  • Perhaps, these recommendations don't exist. REST over HTTP also has limitations (not enough verbs, not enough codes, not enough semantics to cover all the possible scenarios). That's why I asked. Recommending devs to implement RPC for command-like operations (out of the range of CRUD) it's also a recommendation and it could be a good practice as soon as it solves the problem and the solution is consistent. Your main goal is not to build a state of the art API REST. It's to solve a problem. Be pragmatic, don't be a REST fanatic. – Laiv Oct 31 '18 at 10:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.