What does the term Server Stub mean in the context of the Swagger ecosystem? How is it used?
From a swagger tutorial:
With SwaggerHub, you can easily generate a server stub (an API implementation stub) for Node.js, ASP.NET, JAX-RS, and other servers
and frameworks. The server stub is a good starting point for
implementing your API – you can run and test it locally, implement the
business logic for your API, and then deploy it to your server.
https://app.swaggerhub.com/help/apis/generating-code/server-stub
and a stub is:
method stub or simply stub in software development is a piece of code used to stand in for some other programming functionality. A stub may simulate the behavior of existing code (such as a procedure on a remote machine, such methods are often called mocks) or be a temporary substitute for yet-to-be-developed code. Stubs are therefore most useful in porting, distributed computing as well as general software development and testing.
https://en.wikipedia.org/wiki/Method_stub
Stub the API means : create à mock to serve examples described in swagger file.
This mock can be formatted in specific languages/ framework
Server stubbing can be quite powerful depending on the backend platform and framework you plan to use for your API.
For example, you may choose Apache (common in Linux environments) or ASP.NET (common for IIS). The server "stubs" being generated will typically be a deployable library to that specific platform. What you typically get is:
Routing to your business logic. The framework will handle the HTTP specification, but actually mapping from a "controller" to your service layer is being handled by the code generator, based on your API specification.
Serialization and Deserialization of your models (applies to strongly-typed languages like Java/C#).
AuthN/AuthZ may be handled, to some degree, based on the framework's support for your API's chosen auth scheme.
tl;dr: A server stub is intended to be a ready-to-deploy application that routes HTTP requests to your actual business logic on the backend.
From my experience and peers, I found stub to be a mock function or a placeholder function where you can fill in the proper implementation later.
Related
I need to write a Java web application to call a function Meteor APP. One way is through API call. Are there any other means to call Meteor function from 3rd party application.
Thanks
Murali
It all depends on what your requirements are, how your Meteor app is structured, and what sort of integration you desire.
If you are wanting your Java web application to be able to natively call Meteor methods or subscribe to publications, then you will have to use a Java DDP Client to do this. Fortunately, there is at least one documented Java DDP client that you can use for this (and probably many others out there is you search). For your reference, here is a compiled list of DDP clients for other languages/technologies.
If on the other hand you don't want to interface with you meteor app using DDP, then you could always implement a REST API in your meteor app. There are several packages available to do this, but I would highly recommend the simple:rest package.
This package automatically creates a REST API for all your existing publications and methods without any extra code (just simply add the package to your meteor app). If you do need to configure or modify the REST API, the package also provides several options that you can use in your publication or meteor method definition. The package also enforces all your app's security rules and authorization.
For example, if your app had a publication called openTasks, then the corresponding REST endpoint would be.
GET /publications/openTasks
There are quite a few packages at https://atmospherejs.com/?q=rest that can expose your Meteor methods as RESTful API points which your Java app can consume.
I've recently come across the term api and from what I have known api is a interface that connects/integrates between two programs and it can run on any platform.
And again from java we know that it turns it's source code into bytecodes and this bytecode can run on any platforms since it is platform independent.
So my question is does api work/run just like as a bytecode to provide multi-platform functionality
And if not is there any similarities between them or thier process? If please anyone could explain it to me it would be a great help. Thanks in advance.
API does not work like bytecode
Actually, API and Bytecodes are a completely different thing
For Bytecode,
let's try to understand it in java. java compiler compiles a java program then produce bytecode. Then the bytecode is interpreted by java interpreter in different machines and generate different executable files as the requirement of different machines and os.
this is how java maintains it's multi-platform property
Now, API,
API stands for Application Programming Interface. An API is a software intermediary that allows two applications to talk to each other. In other words, an API is the messenger that delivers your request to the provider that you’re requesting it from and then delivers the response back to you.
there are many types of API's out there
but I think you are referring to Web API and it's multi-platform functionality and how it works.
A Web API is an application programming interface for either a web server or a web browser
A Web API works as server-client architecture.
client request to server through HTTP protocol, server responds to client through HTTP protocol
actually whole api service is provided through HTTP protocol, and this api service can provide to any device using HTTP protocol
this has nothing to do with bytecode
The functions for operating the restful api is quite same. Is there any project that can generate the source code for different platform such android,ios and backend stuff.
I suggest you to use API description languages such Swagger ou RAML.
After having described your RESTful application with a language like this, you will be able to generate things like server skelekons and client sdks with different technologies and languages. You can even generate documentations.
With Swagger, swagger-codegen will do that. swagger-ui may also interest you for the documentation part.
To finish, I would like to mention the Restlet studio that allows to define graphically and quickly the structure of RESTful applications and generate then the corresponding Swagger and RAML contents. The APISpark plaform provides a mecanism to introspect Restlet applications and generate the corresponding contents with these languages. It also allow you to generate a set of server skelekons and client sdks.
Hope it helps you.
I will suggest you to use Spring RESTful webservices starter kit. Which will manage your back-end with centralized database. Also Spring has its own android libs to communicate with REST Apis.
I have to integrate with a third-party web-service (behind firewall), and I do have their WSDL and proxy class.
I want to develop the client stuff outside the firewall.
What is the best approach to mock the web-service to ease integration with them?
Do I create a web-service project on my side? Somehow use their proxy classes ad mock the methods? This would create the service references so I can just change the target URL when the time comes.
Or do I create a service layer that returns mock classes in my dev. environment but would use real web-services at run-time?
The former approach would take a lot of work, I would think.
Any ideas?
With just the WSDL, you could host a mock service using soapUI.
I've used the latter approach to good effect in our projects. I've usually found that my apps use a subset of the functionality exposed by a given web service's API, to it's usually made good sense to expose a simpler API to my client code that's more streamlined and that reflects the workflow of my client better. So, since the way I typically use web services already involves writing an abstraction layer, replacing the endpoint on the other side of my adapter classes with a mock service is a very low-friction way to test interaction with the service.
I'm implementing a WCF web service based on WF. This web service consumes other web services which I'm not in charge of. So basically my service workflow contains several Send activities.
I'm following the TDD approach, so the service implementation is to be covered by unit tests. I want to test proper invocation of 3rd party services.
In a non-workflow case I would mock the external services via NMock. But in my case I cannot control the instantiation the workflow instance and I have no idea on how to trick the Send activities to use the mock objects instead of real services endpoints.
Although Unit Testing Workflows And Activities article on MSDN mentions mocks I couldn't find any complete example of mocking the remote end of Send activity.
Any idea on how to do that?
please try Moles framework. http://research.microsoft.com/en-us/projects/pex/
There are samples about how to mock the sharepoint service. I believe the same trick should apply to WF workflow.
I have tried to mock the sqlconnection, Entity framework, web service call, it works very neat. Basically, it can mock almost any .net objects.
Using ServiceAgents wrappers for your web services would be one possible way of doing it.
This is a pattern i have followed in previous projects of mine.
Since they are interface based, you can easily mock out the services.
There are other advantages to this pattern (besides unit testing) including being able to abstract your application from external dependencies to a certain extent. However it does add the overhead of creating another class layer on top of the services.