tag:blogger.com,1999:blog-5239535491482352731.post4900246029653752690..comments2023-07-17T15:55:27.867+03:00Comments on Tarlog on Java: Why REST? Or "Simple vs. Easy"Unknownnoreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5239535491482352731.post-86921814503780866822014-12-31T17:01:04.312+02:002014-12-31T17:01:04.312+02:00@Nick,
Btw what tools do you use to generate your...@Nick,<br /><br />Btw what tools do you use to generate your REST APIs?<br /><br />Currently I'm looking for such tools and there are so many...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-34137917700177500422012-04-12T15:24:04.118+03:002012-04-12T15:24:04.118+03:00I fully understand your point. I myself thought th...I fully understand your point. I myself thought this way ~3-4 years ago, when I first needed to create RESTful APIs, so starting from xml was a natural choice. After all we all have been used to SOAP.<br /><br />But now I don't think XML is a must. <br />I don't think that having a strict schema is a must. Actually I think that a strict schema makes more problems than benefits.<br />(I tried to summarize it here: http://tarlogonjava.blogspot.com/2012/04/rest-best-practices-use-json.html)<br />And I don't think that making client's life a bit easier by providing an XSD is a must. If a client must connect to you, it will regardless if you provide an XSD or a document describing your API.<br />And if your goal is to make client's life easy, you need not provide an XSD, but a library that connects to your APIs.<br />But nothing will make the client more frustrated, if you provide an XSD and the generation will not work as expected. After all you don't know which technology the client uses and you have not tested your XSD with it. And now instead of creating a set of simple classes, a client is busy understanding why the generation didn't work as expected. And this is exactly what everyone hated about SOAP.Tarloghttps://www.blogger.com/profile/13975169847288972544noreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-53377035112273783072012-04-12T14:53:09.126+03:002012-04-12T14:53:09.126+03:00Thanks for the clarification about Jertsey - didn&...Thanks for the clarification about Jertsey - didn't know that :)<br /><br />About XSD/DTD - the point I wanna make is that having XSD allows simple creation of Object Model on client side and so easy usage of server RESTful API.<br /><br />I believe, this is the main reason developers prefer SOAP when accessing web services - the ease of implementation of client side.<br /><br />So having XSD, autogenerating Object Model and then accessing it seamlessly with JSON-JACKSON is or more generally - JAX-RS is a good way to go. <br /><br />JAX-RS allows annotation level selection of underlying format XML/JSON so it's good to have as an option!Alexander Sternhttps://www.blogger.com/profile/14586533705849601980noreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-33313956300299607022012-04-12T14:44:42.378+03:002012-04-12T14:44:42.378+03:00Btw, I wrote some more posts about my view of a RE...Btw, I wrote some more posts about my view of a RESTful APIs, see http://tarlogonjava.blogspot.com/search/label/rest-designTarloghttps://www.blogger.com/profile/13975169847288972544noreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-75219789482815758242012-04-12T14:43:10.515+03:002012-04-12T14:43:10.515+03:00@sternet
I kinda got lost in your comment. Jersey ...@sternet<br />I kinda got lost in your comment. Jersey is a reference implementation for JAX-RS.<br /><br />Talking about JSON ORM tools, personally I prefer Jackson. It can work with POJO without writing any Jackson related code or putting annotations. <br /><br />XSD is a different story. May be I'll write a separate post how do I think it should work. In general, I think that XSD is an overkill, even for XML and surely for JSON. XSD has many type definition some of which has no parallel in JAVA. JSON has no type definitions at all. If you are looking for a standard, DTD may be better in this case.<br />But I even don't think that you must stick to a standard, publish your schemas in any readable format, even as a wiki page. So your clients will need to do some job to create their ORM level. So what? It's one time job anyway.Tarloghttps://www.blogger.com/profile/13975169847288972544noreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-22927950288444407702012-04-12T10:56:56.536+03:002012-04-12T10:56:56.536+03:00I think Jersey some JSON ORM tools like Jettison a...I think Jersey some JSON ORM tools like Jettison and JAX-RS are wonderful starting point technologies for creating and consuming RESTful API in Java.<br />Of course, similar tools probably exist for .NET and other languages.<br />Plus if we make sure to at least maintain XSD schemas for the objects being pass as well as consistent URI structure, the integration becomes much easier and doable.Alexander Sternhttps://www.blogger.com/profile/14586533705849601980noreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-67651735933263545772012-04-11T09:22:22.761+03:002012-04-11T09:22:22.761+03:00Hi Nick,
My point was that REST in not a standard ...Hi Nick,<br />My point was that REST in not a standard therefore it lacks the tools the exist for SOAP to generate client/server sides for multiple languages, technologies and platforms. Of course you can create some kind of standard for your project/organization and generate API out of it. But the main question: when you expose your API to the clients. Can you use the autogeneration tools? Or do you provide such tools for multiple technologies?Tarloghttps://www.blogger.com/profile/13975169847288972544noreply@blogger.comtag:blogger.com,1999:blog-5239535491482352731.post-76508823717168711352012-04-10T20:30:09.695+03:002012-04-10T20:30:09.695+03:00Well, I've developed an auto-generated RESTFul...Well, I've developed an auto-generated RESTFull API :-)Nickhttps://www.blogger.com/profile/06955895749920431598noreply@blogger.com