HTTP API Specs

HTTP API Specs: "A collection of RFCs and other specifications, useful when designing and implementing HTTP APIs."

HTTP	Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Links	Web Linking
Links	URI Template
Links	IANA Link Relation registry
Generic Media Types	JSON Hypertext Application Language
Generic Media Types	Siren
Generic Media Types	Collection+JSON
Other Media Types	Problem Details for HTTP APIs
Other Media Types	Home Documents for HTTP APIs
Semantics	The ‘profile’ Link Relation Type
Negotiation	Prefer Header for HTTP
Caching	HTTP Cache-Control Extensions for Stale Content
Security	Hypertext Transfer Protocol (HTTP/1.1): Authentication
Security	The OAuth 2.0 Authorization Framework
Security	The OAuth 2.0 Authorization Framework: Bearer Token Usage
Security	OpenID Connect Core 1.0
Security	IANA HTTP Authentication Schemes registry
Syntax	Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Syntax	Uniform Resource Identifier (URI): Generic Syntax

'via Blog this'

One API, Many Facades?

One API, Many Facades?: "Web APIs increasingly have several kinds of consumers with different needs. Microservice architectures can encourage us to deploy fine-grained API facades for those needs (the so-called experience APIs or BfF patterns), but this can become an anti-pattern if you have too many distinct consumers to please, especially if you’ve got only a small team to take care of all those front ends.

Be sure to do the math! Before going one way or another, you have to study the cost of your options and whether or not you can support them. Creating different variants of an API has a cost, for the implementor as well as for the consumer, that depends on the adopted strategy. Also, once you’ve unleashed your API and given it to its consumers, perhaps it’s also time to rethink  and refactor this API, as maybe you didn’t take those special device or consumer requirements well enough into account during the design phase.

If you have dedicated teams for these API facades, then it’s an option to consider. When you don’t have that luxury, there are other ways to customize payloads for your consumers without the induced complexity, with simple tricks like field filtering or the Prefer header up to full-blown solutions like custom media types or specifications like GraphQL.

But you don’t necessarily need to fire the big guns, and could opt for a middle path: one main, full API plus one or two variants for mobile devices, and you are likely going to meet the requirements of all your consumers. Consider including a pinch of field filtering, and everybody will be happy with your APIs!"



'via Blog this'

JAX-RS 2.0 : Server side Processing Pipeline | Thinking in Java EE (at least trying to!)

JAX-RS 2.0 : Server side Processing Pipeline | Thinking in Java EE (at least trying to!): "The inspiration for this post was the Processing Pipeline section in the JAX-RS 2.0 specification doc (Appendix C). I like it because of the fact that it provides a nice snapshot of all the modules in JAX-RS – in the form of a ready to gulp capsule !"



'via Blog this'

REST and Web Services links

How to design a REST API

http://blog.octo.com/wp-content/uploads/2014/12/OCTO-Refcard_API_Design_EN_3.0.pdf

Best Practices for Designing a Pragmatic RESTful API

 Good article on #SOA and #REST alignment http://t.co/OJutT8AiKS

Web Application Description Language


REST API Documentation Using JAXRS-ANALYZER


SWAGGER The World's Most Popular Framework for APIs

The Swagger framework addresses server, client, documentation, and sandbox needs for RESTful APIs.^{[citation needed]}

As a specification, it is language-agnostic. It is also extensible into new technologies and protocols beyond HTTP.^{[citation needed]}

With Swagger's declarative resource specification, clients can understand and consume services without knowledge of server implementation or access to the server code.^{[citation needed]}

The Swagger UI framework allows both developers and non-developers to interact with the API in a sandbox UI that gives clear insight into how the API responds to parameters and options. Swagger may utilize both JSON and XML.