3

I am writing a RESTful service in Java, of course it's typical HTTP based interface.

I am wondering should the service provide Java interface which has same semantic to the RESTful interface? I think Java interface will ease other Java code to call the service. (Client Java code doesn't need to use HTTP client to trigger HTTP requests to invoke RESTful) The problem is it's difficult to write same semantic Java interface to a RESTful one, I mean same semantic.

Any advice for the design? Thanks!

  • you use that word "idempotent", it doesn't mean what you think it means – Javier Jul 16 '13 at 14:00
  • @Javier I changed to use 'same semantic'. – 卢声远 Shengyuan Lu Jul 16 '13 at 14:01
  • What do you mean by "Java ones"? Are you talking about using serialization? Or are you going to provide your server code as a library that they can then access directly? – beatgammit Jul 16 '13 at 14:16
  • @tjameson "Java ones" == "Java interfaces". Yes, access directly. – 卢声远 Shengyuan Lu Jul 16 '13 at 14:21
4

The problem is it's difficult to write same semantic Java interface to a RESTful one, I mean same semantic.

What is difficult about it? The standard way of doing REST interfaces in Java consists of writing a Java interface and adding some JAX-RS annotations, that's all.

  • It's a good point! – 卢声远 Shengyuan Lu Jul 16 '13 at 14:22
  • Another question: How does remote Java clients call the RESTful? Use plain HTTP client? Or jersey client library? Thanks! – 卢声远 Shengyuan Lu Jul 16 '13 at 14:37
  • @卢声远 Shengyuan Lu: however the developer of that client wants - that's the point of having a standard. Using the Jersey client could save some work but is not necessary. – Michael Borgwardt Jul 16 '13 at 15:01
0

I don't write in Java, but the same concepts apply.

For most projects I work on, I try to do both. Basically my project is set up such that the REST interface just uses the underlying API. Basically the flow is:

REST -> Front-end API -> Useful code

This way I can write additional front-ends for the same backend. I don't generally release the API, but I try to keep it in a state that if it needs to be released, it can be.

For example, in one project, I needed to open up a TCP API using JSON, and provide UDP output packets. Since everything was already going through the standard API, this was dead simple.

In answer to your question, I would only release the REST API (as @MichaelBorgwardt pointed out, this isn't as terrible as it sounds) so you only have to officially support one, but definitely keep them separate so it's easy to release it as a library or add a different front-end.

0

Look at your requirements. Do you have a solid requirement for REST? Is this customer facing or internal? The answers to these questions may answer it for you.

If external, I would just do REST and be done with it. If internal, look at your consumers and make a decision. I would do one or the other though and not both.

0

If you have the resource to create Java interface, go for it. I'm sure that REST API is your core API, usually because it's a client-server system. It's not hard to write client code calling REST api directly but it also longer and if you use it a lot you'll see repetitions all over the place.

What usually happens is you write a native wrapper for most frequently used interfaces to help people writing client applications. It also gives an extra benefit that when you change your REST interface you can just update the wrapper, e.g. when you change REST api from returning application/json to application/hal+json your wrapper still returns array of objects.

You can see this everywhere. Twitter, for example, has more than one Java wrappers. Obviously they don't have time to write wrapper for every language out there, but it's also very useful that a lot of people put time in writing one.

Your Answer

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

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