sahan / robozombie Goto Github PK
View Code? Open in Web Editor NEWEffortless networking for your Android application.
Home Page: http://sahan.me/RoboZombie
License: Apache License 2.0
Effortless networking for your Android application.
Home Page: http://sahan.me/RoboZombie
License: Apache License 2.0
Only HttpStatus.SC_OK
(a response code of 200) is being treated as a successful operation. Refactor to accept all response codes of class 2xx.
Allow inherited components to be skipped selectively for a particular request definition using an @Skip
annotation.
Introduce an annotation named @Detach
which can be used to disinherit metadata defined at the endpoint level. This feature should only be activated on metadata which makes sense to be detached - such as @Serializer
, @Deserializer
and @Async
.
It would eliminate repetitive metadata definitions to accommodate a request which strays from the norm. For example, an asynchronous endpoint with just one synchronous request.
Refactor the current design of creating and growing requests by decoupling each unit of work to a pipeline segment and chaining them to produce the final request. Identify any dependencies among the processors and their hierarchy therein. Differentiate recoverable and unrecoverable segments in the pipeline. Allow for multiple pipelines with different segments and/or varying segment combinations.
Refactor @Endpoint
to accept a single coherent URI string. It's safe to assume that the user will provide a syntactically correct URI. In this case, individual parameters will just be an obtrusion and affect the API UX as well. A single required string parameter would be more concise and mandate a URI. A bare minimum would be scheme://domain
.
Fix JsonDeserializer
for proper usage of TypeToken
with parameterized types.
Refactor the current design for handling responses and parsing entities by decoupling each unit of work to a pipeline segment and chaining them to produce the final result. Identify any dependencies among the processors and their hierarchy therein. Differentiate recoverable and unrecoverable segments in the pipeline. Allow for multiple pipelines with different segments and/or varying segment combinations.
Revise the current design for response parsing via @Parser
, ParserType
and AbstractResponseParser
to clearly define its role as a content deserializer. This establishes the definition for the output as being a model rather than a parse tree - where a parse tree would be an intermediate step to arriving at a complete model. In addition, it conveys the idea that a content format used for transmission should be converted to an object state in memory.
Refactor @Parser
to @Deserializer
and AbstractResponseParser
to AbstractDeserializer
. Deprecate ParserType
and allocate a ContentType
to all prefabricated deserializers. Retain the rules for annotation overriding at request level.
Similarly, allow request entities to be serialized to the specified ContentType
using a set of prefabricated serializers identified by @Serialize
.
Given below is a sample endpoint definition with separate serializers and deserializers.
import static com.lonepulse.robozombie.annotation.Entity.ContentType.*;
import static com.lonepulse.robozombie.annotation.Request.RequestMethod.*;
@Serializer(JSON)
@Deserializer(JSON)
@Endpoint("www.example.com")
public interface TravelPlannerEndpoint {
@Request(path = "/travellers/{id}")
Traveller getTraveller(@PathParam("id") String id);
@Request(path = "/travellers", method = PUT)
void putTraveller(@Entity Traveller traveller);
@Deserializer(XML)
@Request(path = "/routes?{waypoints}")
Route getRoute(@PathParam("waypoints") String waypoints);
}
Enforce all execution failures to be acknowledged consistently regardless of whether they are request failures without a 2xx
type response code or an erroneous request execution.
Introduce a context aware RequestFailedException
which will be thrown for all execution failures. It should support access to the invocation context which initiated the failed request, provide the response if available and produce a stack-trace which identifies any root cause.
Refactor the current design for populating request parameters using the generic model of annotating an endpoint request argument with @Param
or using @Request.Param
on the request itself. This mapping should result in a request parameter whose format and mode of usage conforms with its HTTP/1.1 request method (as defined in Section 9 of the RFC).
Looks like those project are close, what are the differences ?
Facilitate the provision of a custom configuration for an endpoint to tailor properties such as schemes, timeouts, number of pooled connections ...etc. Expose a template, Zombie.Configuration
which can be extended as required to configure the properties and allow these custom extensions to be identified on an endpoint interface via an @Configuration
annotation.
The current approach for parsing JSON or XML response content with @Parser
using ParserType.JSON
or ParserType.XML
is tightly coupled with GSON and JAXB. From an API user's perspective this would be an imposition. In addition, if the API user opts for another library for JSON parsing, the GSON dependency will simply be an overhead.
Current dependency on JAXB is to be dropped in favor of Simple-XML which is more lightweight and Android friendly.
Offer the prefabricated JSON and XML response parsers only when GSON or Simple-XML is detected on the classpath. Issue a warning on class-loading and an informative error upon usage of either parser in the absence of the required libraries.
Allow endpoints to use the HTTP PATCH method for requests. This method should be treated in conformance with IETF RFC-5789.
The test suite contains an endpoint which relies on the API at ICNDB. Migrate all these test cases to the MockEndpoint
contract.
Allow interception of requests for custom processing just before they are executed. This allows the API user to hook into the very end of the request processor chain and manipulate the request under-the-hood. Such interaction might be required to circumvent any rigidity in the current API which would otherwise disable a successful request execution.
Provide a generic Interceptor
contract which all interceptors must implement and allow them to be attached via an @Interceptor
annotation or be passed in as a request parameter.
Allow the provision of packages prefixes to identify the domains whose types should be scanned for wired endpoints. This is a rudimentary solution to confining the search space when traversing up an inheritance hierarchy to look for injection targets.
Allow the explicit identification of query params by @QueryParam
, form-url-encoded params by @FormParam
and entities to be enclosed by @Entity
. This is a divergence from the generic model of using @Param
for GET, POST and PUT requests.
The generic model makes a set of assumptions which might make it impossible to define contracts for certain endpoints. With these annotations we have more flexibility and it eliminates API ambiguity. However, adhere to HTTP/1.1 (as defined in Section 9 of the RFC) where possible and give a polite warning when usage deviates.
P.S. consider deprecating @Param
- which now seems redundant... Tim Toady Bicarbonate?
So far, constructor injection for endpoints seems to have no redeeming features over field or setter injection. Its current implementation (at v1.2.3) is not quite comprehensive as one would want it to be. Even if it was to grow, usage would undoubtedly be unwieldy. It will be unusable if the design (e.g. a factory method) doesn't permit it, or more importantly if a full-fledged DI container is already being used.
No deprecation cycle will be followed.
Eliminate the need for a separate @Rest
annotation on RESTful requests. Currently, this annotation is used only to detect the potential existence of path parameters - defer this to the generic @Request
annotation.
P.S. maintain backwards compatibility on the next 1.3.0 semantic version and follow a deprecation cycle till the next major release.
Short question: is RoboZombie supposed to work in an app that was minified by ProGuard? If so, is any special configuration needed in proguard-project.txt
?
Allow identification of query and form parameters as a map of name and value pairs using two separate annotations, @QueryParams
and @FormParams
. This should provide a much more concise definition for requests with many query or form parameters.
Allow constant query and form parameters to be specified using the same annotations with a common @Param
annotation.
The existing annotation @Request
should be altered for use as a meta-annotation on more succinct types such as @GET
and @PUT
. This abbreviates the definition and clearly expresses the method type.
As an afterthought, this would provide a stepping stone for custom API user annotations annotated with
@Request
should such supporting features ever be considered.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.