2 added 577 characters in body
source | link

Yes, it is future proof (until technology X replaces it, just like REST replaced others)

REST is not Microsoft Technology. It is the protocol almost all APIs use.

https://en.wikipedia.org/wiki/Representational_state_transfer

Edit: Future Proof is mainly a software architecture issue

So you do not sprinkle you code with

context.httpClient.get( .. )

all over the place

But use one class/function

getContent(){
  return  context.httpClient.get( .. )
}

That way you have abstracted your code, can work with other data retrieval methods (like getting data from a localStorage cache) and it is easier to test.

And Microsofts'commitment

PnP Core JS is all about abstracting the REST interface for you

https://dev.office.com/patterns-and-practices

Yes, it is future proof (until technology X replaces it, just like REST replaced others)

REST is not Microsoft Technology. It is the protocol almost all APIs use.

https://en.wikipedia.org/wiki/Representational_state_transfer

Yes, it is future proof (until technology X replaces it, just like REST replaced others)

REST is not Microsoft Technology. It is the protocol almost all APIs use.

https://en.wikipedia.org/wiki/Representational_state_transfer

Edit: Future Proof is mainly a software architecture issue

So you do not sprinkle you code with

context.httpClient.get( .. )

all over the place

But use one class/function

getContent(){
  return  context.httpClient.get( .. )
}

That way you have abstracted your code, can work with other data retrieval methods (like getting data from a localStorage cache) and it is easier to test.

And Microsofts'commitment

PnP Core JS is all about abstracting the REST interface for you

https://dev.office.com/patterns-and-practices

1
source | link

Yes, it is future proof (until technology X replaces it, just like REST replaced others)

REST is not Microsoft Technology. It is the protocol almost all APIs use.

https://en.wikipedia.org/wiki/Representational_state_transfer