Having a legacy on prem SOAP API, need to expose it to the vendor to call in, however, vendor preferred API in oData feed. Newbie in odata myself, not sure how would it work and if it at all possible. My thought is to write an API tier translating the odata call to a SOAP call? thoughts?
This is a very similar question to here: Is it possible to query a soap endpoint via odata?
Here is the answer I gave for that question:
You could create an OData wrapper around a SOAP endpoint but I don't
think that it is worth it.
The OData service would allow filtering, ordering and selecting by all
of the properties (amongst other things) and the SOAP service may not
allow all of this so your OData service would probably have to go and
get all of the data and then post process it which loses the main
benefit of OData in that you can do all of the filtering and sorting
on the server side. You may as well just get the data client side and
filter it there.
If your SOAP service somehow does have all of this support then yes,
you could write an OData wrapper for it and get these benefits but it
would still be a lot of work to convert all of the different possible
queries into something that your SOAP service can handle.
I don't know your reasons for wanting an OData wrapper but it seems
like this might be a lot of work for minimal benefit but it all
depends on your use case.
I think that this is a very similar case here, writing an OData wrapper for this would be lot of work and wouldn't give many benefits. If you are using entity framework/web.api then it might not be too much work to do to write a new OData service to expose the functionality that they need and there are a lot of tutorials around (like this) that should help get you started but otherwise, it might be worth seeing whether they can consume your existing services or something similar!
Related
I'm trying to start a little microservice application, but I'm a little bit stuck on some technicalities.
I'm trying to build an issue tracker application as an example.
It has 2 database tables, issues and comments. These will also be separate microservices, for the sake of the example.
It has to be a separate API that can be consumed by multiple types of clients e.g. mobile, web etc..
When using a monolitic approach, all the codebase is coupled together, and when making a request to let's say the REST API, I would handle for example the '/issues/19' request
to fetch the issue with the id '19' and it's corresponding comments by means of the following pseudocode.
on_request_issue(id) # handler for the route '/issues/<id>'
issue = IssuesModel.findById(id)
issue.comments = CommentsModel.findByIssueId(id)
return issue
But I'm not sure on how I should approach this with microservices. Let's say that we have microservice-issues and microservice-comments.
I could either let the client send a request to both '/issues/19' and '/comments/byissueid/19'. But that doesn't work nice in my point of view, since if we're having multiple things
we're sending alot of requests for one page.
I could also make a request to the microservice-issues and in that one also make a request to the microservice-comments, but that looks even worse to me than the above, since from what
I've read microservices should not be coupled, and this couples them pretty hard.
So then I read about API gateways, that they could/should receive a request and fan out to the other microservices but then I couldn't really figure out how to use an API gateway. Should
I write code in there for example to catch the '/issues/19' request, then fan out to both the microservice-issues and microservice-commetns, assemble the stuff and return it?
In that case, I'm feeling I'm doing the work double, won't the API gateway become a new monolith then?
Thank you for your time
API gateway sounds like what you need.
If you'll keep it simple, just to trigger internal API, it will not become your new monolith.
It will allow you do even better processing when your application grows with new microservices, or when you have to support different clients (browser, mobile apps, watch, IOT, etc)
BTW, the example you show sounds like a good exercise, in reality, for most webapps, it looks like over design. I would not break every DB call to its own microservices.
One of the motivations for breaking something to small(er) services is service autonomy, in this case the question is, when the comments service is down should you display the issue or not- if they are always coupled anyway, they probably shouldn't reside in two services, if they aren't then making two calls will let you get this decoupling
That said, you may still need an API Gateway to solve CORS issues with your client
Lastly, comments/byissueid is not a good REST interface the issueId should be a parameter /comments/?issueId=..
I've recently read about the advantages (and disatvanteges) of GraphQL over Rest API.
I am developing a webpage that consumes several different Rest APIs and Soap services. Some of those services are dependent, meaning that a result from Rest1 will be passed as a parameter to Rest2 which will be passed to Soap service for a final return value.
From what I understood, GraphQL deals with multiple data sources and query nesting, but I have not yet understood if it will handle those nested dependent queries.
Can anyone that worked with several data sources that are dependent with GraphQL tell me if it can be done? My project should be up in 2 weeks and investing time in learning and setting up GraphQL and ending up not using it because it's not supporting my case would be a big failure for me.
Note: the APIs and services are not mine, I am consuming them from an outside source
I'm assuming you haven't yet setup a GraphQL server. Once you do, you can see how this isn't too difficult. So, I'd recommend you setup your own server first. The Egghead Course, "Build a GraphQL Server" got me started, but it's not free.
In essence, you'll be setting up your schema then defining how to resolve with data. When you resolve, you can setup an express server to query a database, or you can hit a REST interface, or hit your SOAP interface. How you retrieve the data is up to you, so long as you return it in compliance with your defined schema.
Hope that makes sense. Mocking up a mini app to demonstrate is possible, but since I don't have one handy, this is the best advice I can offer.
I have been working on a mobile app that sends an ajax call to the server and waits for a response from the server in json format.
I am wondering from the server side, how to respond to an ajax call? Could someone give me an example in code?
I check the server code of my project (written by other members of the team) and could not understand it. I can only see it is written in java and also some keywords such as apache, springframework, etc pop up. I am a total newbie for server side programming and I want to learn more about it. Could someone give me some tips on how to get started with those as well? How does a server work? Is it just like responding to various request? What language could you use to build it and what is Apache? I know this looks like a lot of questions so probably I need to get some basic knowledge first. Any help/tips/suggestions on readings is appreciated.
This is kind of a broad question, as there are a lot of different server-side technologies that can handle server side AJAX requests, but if you want to go the Java route, using Spring Framework makes it very easy.
Spring Framework is a large open-source Enterprise Java framework that has a variety of features which entire books rarely even cover.
(Apache is an open-source project that contains over a hundred different sub-projects, the most popular being a web server.)
Spring does have some specific tools to handle REST calls. Assuming your AJAX is making a REST call (which is what it sounds like), and your project is already using Spring framework, it is fairly straightforward (assuming you already know Java). The Spring framework handles all the hard stuff for you. There are a few different ways to do this using Spring, but check out this link for creating a simple REST service:
https://spring.io/guides/gs/rest-service/
Another route would be to look into PHP, which is a server-side scripting language. With PHP, you can handle AJAX requests without the need for an application server (most basic web servers speak PHP). There are plenty of good resources for this, but one of my favorites is http://www.tutorialspoint.com/php/
BTW - the TutorialsPoint site is great for Java and Spring as well
I'm currently looking at the feasibility of converting our current WCF Data Services OData provider to Web API OData.
I'm just a little confused at the OData implementation for Web API. With WCF Data Services it sits over the top of our ADO.Net entity model which exposes a bunch of tables from the SQL Server backend, i.e. you give WCFDS the ADO model to generate and then you have access to all of the tables through the standard OData syntax.
With Web API from all reading so far do we create a controller or separate actions for every table/object that we want to expose? Am I missing something? Is there just a way where the OData Web API controller can just expose the entire model from the ADO Data model? Having to create a action for every table would be a mess and overkill.
Currently if we need to add a table we just map it in the EDMX and WCFDS will automatically expose it as it's mapped to the entire context of the model.
Generating the model(s)
You can:
Use the convention model builder from ASP.NET Web API. This generates a different model than what EF's own convention model builder produces: an EdmLib IEdmModel. See this question though if you're using model-first or database-first. This method seems really backwards, and it is, but it mostly works.
Serialize the EF model and rebuild it as an IEdmModel (see this question). Again this is really inefficient. If you're using model-first or database-first, you'll want to just deserialize the EDMX file to build the IEdmModel. It still produces a different model internally, but at least the CDSL is a more stable format than CLR code conventions, so you'll probably have less surprises than you'd get when using two different convention-based model builders.
The reason for this is that ASP.NET Web API OData extensions use EdmLib, while EF uses its own code, and there is no plan to make them work together. Maybe you'll find this rant useful if you're curious.
Working on the API
Once you've generated the model from a unique source (so that you can work on your model from a single place), you'll indeed have to create a controller per entity, basically. The point of Web API is not to build things automagically, but to offer flexibility to the developer. The EntitySetController helps reducing redundancy, but it won't offer everything out of the box.
Taking a step back
In the rant mentioned above, I also talk about the difference between a service-layer API and a data-layer API. ASP.NET Web API is better suited for services, while OData makes services awkward. On the other hand, OData makes data access a breeze (essentially being like a RESTful SQL) and by virtue of being directly attached to the data model, can automate a lot of things as you saw with WCF Data Services. ASP.NET Web API with OData extensions sits in the middle, and its value is not universally agreed upon (using certain bits of OData URI syntax on service APIs is certainly useful though).
Don't get too hyped up by the recent buzz around ASP.NET Web API, it and WCF Data Services are very different beasts and run on different layers in your design. Indeed, in a multi-tier architecture, you could very well see a service API built using ASP.NET Web API sitting on top of an OData API built using WCF Data Services.
My advice is think carefully about what you're trying to build, and depending on the answer, either choose ASP.NET Web API and embrace the fact that the API you expose will be very different from a data-centric OData API, or stick with WCF Data Services.
A possible plan
You can find a lot of material on the web about service-layer APIs on the web by searching for terms like "non-CRUD web/RESTful/hypermedia API" or by comparing products like ServiceStack, which advocate for less data-oriented APIs.
If you're still unsure about the nature of your project, prototype it.
If you end up with a bunch of essentially identical controllers with Web API, each mapped to exactly one entity, then your API is heavily data-oriented. Go with WCF Data Services.
If you end up with a lot of OData Actions and awkward entities with WCF Data Services, then you need more domain logic on the server-side of the API, and data-orientation doesn't offer you enough. Go with Web API. A good rule of thumb here is to treat OData actions just like you treat stored procedures in a SQL DBMS. Actually, treat any OData server as a DBMS, because that's what they are. If you wouldn't put it behind a SQL interface, don't put it behind an OData interface.
Important (Update)
It was announced on March 27th 2014 that WCF Data Services would be discontinued by Microsoft in favor of ASP.NET Web API. To handle the "data-layer" use-cases I've exposed here, Microsoft has said that it is planning to extend ASP.NET Web API. Some community efforts are also underway. WCF Data Services will also be open-sourced at some point, so it's not impossible that a new maintainer will takeover, though it's uncertain.
I am planning a new application and have been experimenting with GWT as a possible frontend. The design question I am facing is this.
Should I use
Option A: GWT-RPC and build the app quickly
Option B: Build a REST backend using Spring MVC 3.0 with all the great #Controller, #Service, #Repository annotations and build a client side library to talk to the backend using the GWT overlay features and the GWT Request builder?
I am interested in all the pros and cons and people experiences with this type of design?
Ask yourself the question: "Will I need to reuse the server-side interface with a non-GWT front-end?"
If the answer is "no, I'll just have a GWT client": You can use GWT-RPC, and take advantage of the fact that you can use your Java objects both on the server and the client-side. This can also make the communication a bit more efficient, at least when used with <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, which shortens the type names to small numeric values. You'll also get the advantage of better error handling (using Exceptions), type safety, etc.
If the answer is "yes, I'll make my service accessible for multiple kinds of front-ends": You can use REST with JSON (or XML), which can also be understood by non-GWT clients. In addition to switching clients, this would also allow you to switch to a different server implementation (maybe non-Java) in the future more easily. The disadvantage is, that you'll probably have to write wrappers (JavaScript Overlay Types) or transformation code on the GWT client side to build nice Java objects from the JSON objects. You'll have to be especially careful when you deploy a new version of the service, which brings us back to the lack of type safety.
The third option of course would be to build both. I'd choose this option, if the public REST interface should be different from the GWT-RPC interface anyway - maybe providing just a subset of easy to use services.
You can do both if use also use the RestyGWT project. It will make calling REST based JSON resources as easy as using GWT-RPC. Plus you can typically reuse the same request response DTOs from the server side on the client side.
We ran into the same issue when we created the Spiffy UI Framework. We chose REST and I would never go back. I'd even say GWT-RPC is a GWT Anti-pattern.
REST is a good idea even if you never intend to expose your REST endpoints. Creating a REST API will make your UI faster, your API better, and your entire application more maintainable.
I would say build a REST backend. In my last project we started by developing using GWT-RPC for the first few months, we wanted fast bootstrapping. Later on, when we needed the REST API, it was so expensive to do the refactoring we ended up with two backend APIs (REST and RPC)
If you build a proper REST backend, and a deserialization infra on the client side (to transform the json\xml to GWT Java objects) then the benefit of the RPC is almost nothing.
Another sometimes forgotten advantage of the REST approach is that it's more natural to the browser running the client, RPC is a propitiatory protocol, where all the requests are using POST. You can benefit from client side caching when reading resources in the standard way.
Answering ams comments:
Regarding the RPC protocol, last time I "sniffed" it using firebug it didn't look like json, so I don't know about that. Though, even if it is json based, it still uses only the HTTP POST method to communicate with the server, so my point here about caching is still valid, the browser won't cache POST requests.
Regarding the retrospective and what could have done better, writing the RPC service in a resource oriented architecture could lead later to easier porting to REST. remember that in REST one usually exposes resources with the basic CRUD operations, if you focus on that approach when writing the RPC service then you should be fine.
The REST architectural style promotes inspectable messages (which aids debugging and security), API evolution, multiple platforms, simple interfaces, failure recovery, high scalability, and (optionally) extensible systems via code on demand. It trades per-interaction performance for overall network efficiency. It reduces the server's control over consistent application behavior.
The "RPC style" (as we speak of it in opposition to REST) promotes platform uniformity, interface variability, code generation (and thereby the ability to pretend the network doesn't exist, but see the Fallacies), and customized interactions. It trades overall network efficiency for high per-interaction performance. It increases the server's control over consistent application behavior.
If your application desires the former qualities, use the REST style. If it desires the latter, use the RPC style.
If you're planning on using using Hibernate/JPA on the server-side and sending the resulting POJO's with relational data in them to the client (ie. an Employee object with a collection of Phones), definitely go with the REST implementation.
I started my GWT project a month ago using GWT RPC. All was well until I tried to serialize an object from the underlying db with a One-To-Many relationship in it. And got the dreaded:
com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy
If you encounter this and want to stay with GWT RPC you will have to use something like:
GWT Request Factory (www.gwtproject.org/doc/latest/DevGuideRequestFactory.html) - which forces you to write 3+ classes/interfaces per POJO you want to share with the client. OUCH!
Gilead (sourceforge.net/projects/gilead/) - which appears to a dead project.
I'm now using RestyGWT. The switch was fairly painless and my POJO's serialize without issue.
I would say that this depends on the scope of your total application. If your backend should be used by other clients, needs to be extendable etc. then create a separate module using REST. If the backend is to be used by only this client, then go for the GWT-RPC solution.