I have built an application which acts as an interface between an EAI layer and third party vendor applications. I am using REST-ful web services for this, making use of JAX-RS API and Jersey framework. Although the web services can do different operations like Cancel, View, Create, Reschedule orders, I have implemented all of them as POST methods. But for the web-services to be REST-ful, we need to use the HTTP methods GET, POST, PUT and DELETE appropriately.

Here there are no users who can view the url to be used and hence no 'User Experience' involved. It is just a url configured at the EAI layer, which gets the request from the UI\Order Management screens. In this scenario, do we really need to make the web-services REST-ful? Whatever I have created, can they be called REST-ful web-services?

2 Answers 2


When I summarize your question as:

Should I blindly follow a design approach even though it doesn't provide me any benefit? My only justification is an anticipated, future event that may not ever occur or be an issue.

The answer becomes startling clear -


One of REST's values is in making services easier to consume through a standardized approach. You state that you don't have a need for that. So don't worry about forcing your system into a particular design that doesn't work for you.

If you're worried about maintaining the system and available talent for future developers, just advertise your system as what it is - a collection of services.


I would say that it is just a Web Service not a RESTful one. It is not just a question of being stateless, but also representative of what is being done.

I've found that this article is an interesting one to read: http://www.ibm.com/developerworks/webservices/library/ws-restful/

And no, it is not a question of user experience, it is a question of developer experience and API. As long as you use a standard framework/method another developer can pick up what is left and continue from there. Since you are talking about integration I'd say that it probably would be an excelent idea to make your services RESTful, and have a logical way of handling your WSs.

Then again, I do not have the full context of your project and this is mostly an architecture decision that most be taken considering not only the current use but also the future use and further developements.

But let me stress this once more, it is a third party integration and when doing integrations you should make it as standard as possible

  • So if I make my services REST-ful, the only difference would be that I would be following a standard, making it easier for another developer in terms of maintainability? So am I using non REST-ful REST web-services now? Or can I even call them REST web-services? If not what do I call them :-)
    – Chillax
    Jan 16, 2014 at 11:03
  • Not only someone elses job easier, yours too in the long term. If you read through the internet, by not using the HTTP verbs you can not call your WSs REST or RESTful (RESTful is just "adjectifying" REST) and unless you use standards/protocols (whatever people call them) all you can call them is Web services, nothing else. You might want to take a look at SOAP too, check: en.wikipedia.org/wiki/SOAP and see if it fits your needs
    – IvoC
    Jan 16, 2014 at 11:19
  • I would be able to make my services RESTFUL, by choosing appropriate URL's and HTTP methods, without touching the business logic I hope? And changing my POST to GET/POST/DELETE would only change the way my services are being called, not anything within the web-services?
    – Chillax
    Jan 16, 2014 at 12:49
  • That is correct. Choose the best "verb"/method for each operation you are trying to expose
    – IvoC
    Jan 16, 2014 at 16:15

Your Answer

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

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